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using  low-cost  graphics  hardware  to  produce  acceptable  simulation  of  flight  over 
terrain  generated  from  Defense  Mapping  Agency  (DMA)  digital  elevation  data. 
The  flight  simulator  displays  a  dynamic,  three-dimensional,  out-the-window  view 
of  the  terrain  in  real-time  while  responding  to  operator  control  inputs.  The  total 
system  cost  (software  and  hardware)  of  the  simulator  is  an  order  of  magnitude 
less  than  most  flight  simulation  systems  in  current  use. 
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I.  INTRODUCTION 


Flight  simulation  has  been  an  important  computer  graphics  application, 
embracing  a  range  of  systems  from  a  $32.00  program  for  a  personal  computer 
(Ref.  l]  to  special  purpose  machines  costing  millions  of  dollars  [Ref.  2].  The 
capabilities  of  these  systems  are  spread  across  a  range  nearly  as  wide  as  their 
costs,  with  great  variances  in  speed  (frames  displayed  per  second),  realism, 
flexibility,  and  area  of  flight.  We  present  here  a  system  that  is  relatively 
inexpensive,  yet  still  fast  enough  to  present  a  real-time  three-dimensional  view  of 
digitized  terrain.  We  built  this  system  on  a  commercially  available,  high- 
performance  graphics  workstation,  the  Silicon  Graphics,  Incorporated  IRIS-2400 
Turbo.  The  IRIS  system  was  selected  because  of  its  local  availability  and  its 
performance  capabilities.  The  flight  simulator  presented  here  does  not  use  the 
natural  color  and  shape  of  individual  terrain  elements  (in  order  to  achieve  real¬ 
time  performance),  but  it  is  sufficiently  realistic  to  provide  the  feeling  of  flight 
and  allow  identification  of  the  displayed  terrain  and  targets. 

A.  FOG-M 

1.  Background 

The  project  presented  here  was  built  in  response  to  the  United  States 
Army  Combat  Developments  Experimentation  Center's  need  to  simulate  the 


operation  of  the  Fiber-Optically  Guided  Missile  (FOG-M)  [Ref.  3j,  but  this  missile 
is  also  being  considered  for  use  by  the  United  States  Marine  Corps  [Ref.  4j. 
Simulation  is  necessary  in  order  to  test  and  evaluate  the  tactics,  doctrine  and 
training  requirements  associated  with  the  missile  without  the  expense  and  danger 
of  actual  firings  during  simulated  combat  field  trials.  The  FOG-M  is  a  generic 
family  of  remotely-piloted,  video-guided  munitions,  but  for  the  purpose  of  this 
prototype  simulator,  the  weapons  are  all  logically  equivalent,  and  the  entire 
family  is  referred  to  as  “the  missile.”  In  order  to  avoid  security  constraints,  the 
parameters  and  operational  characteristics  used  in  this  work  were  not  taken  from 
exact  FOG-M  specifications.  The  parameters  and  technical  specifications  are  all 
estimates,  based  on  reasonableness  and  consistency  with  general,  unclassified 
descriptions  of  the  FOG-M. 

2.  Description 

The  actual  FOG-M  missile  is  six  inches  in  diameter,  five  and  one-half  feet 
high,  weighs  eighty-three  pounds,  and  costs  about  $20,000  [Ref.  4].  It  has  a  video 
camera  mounted  in  its  nose,  which  transmits  a  black-and-white  picture  back  to 
the  operator's  console  (which  consists  of  a  television  screen,  a  computer,  and  a 
joystick)  over  the  fiber-optic  link.  (The  simulator  display  offers  the  user  the  choice 
>f  — .tiier  ••oior  or  ;»iack-an«i-white:  color  is  'he  default  for  “he  simulator  despite  the 
operator  view  of  the  missile  being  black-and-white.  The  color  compensates  for 
some  of  the  loss  in  realism  and  identifiability  inherent  in  a  polygonal 
representation  of  natural  objects).  Before  launch,  in  normal  operation,  the  missile 


is  given  a  general  direction  to  a  target  and  the  altitude  of  the  highest  point  within 
its  range.  The  simulator  allows  values  in  excess  of  FOG-M  operational 
capabilities  for  speed,  range,  and  altitude  above  ground  level  (AGL),  but  the 
default  values  of  two  hundred  knots,  ten  kilometers,  and  one  thousand  meters  are 
characteristic  of  this  type  of  missile.  As  soon  as  the  missile  is  in  position,  it  begins 
transmitting  video  images.  When  launched,  the  missile  rises  to  approximately 
two  hundred  feet  above  the  highest  terrain  point,  and  then  levels  off  in  horizontal 
flight  in  the  targeted  direction.  The  operator  controls  the  pan  and  tilt  angle  of 
the  camera  with  the  joystick,  and  can  dial  in  changes  to  the  heading  and  altitude 
of  the  missile.  The  operator  also  has  the  capability  to  loom  the  camera’s  field  of 
view  from  eight  degrees  to  fifty-five  degrees,  and  to  designate  (“lock-on”  to)  a 
target  for  automatic  homing  by  the  missile. 

B.  ASPECTS  OF  FLIGHT  SIMULATION 

There  are  many  aspects  to  flight  simulation.  Modern  commercial  simulators 
provide  sophisticated  mock-ups  of  cockpits  and  controls  and  highly  detailed  out 
the  window  views.  By  mounting  the  simulator  on  a  moving  platform,  a  true  sense 
of  the  physical  feelings  of  acceleration  and  roll  can  be  achieved.  These  systems 
also  cost  miilions  of  dollars. 

One  of  the  first  decisions  that  must  be  made  when  designing  a  flight  simulator 
is,  “For  what  purpose  will  the  simulator  be  used?”  The  answer  to  this  question 
drives  most  of  the  design  decisions  that  have  to  be  made.  Since  the  purpose  of 


this  project  is  to  provide  a  simulation  of  the  FOG-M  missile  as  viewed  from  its 
operator’s  console,  it  is  felt  that  the  most  important  items  to  model  are  the 
simulated  video  display  of  the  terrain  and  the  actual  operator  controls.  The 
terrain  should  appear  realistic  enough  that  its  major  features  are  recognizable  to  a 
person  familiar  with  the  area.  The  controls  should  allow  for  the  same 
functionality  as  the  actual  console.  The  simulator  must,  of  course,  also  provide  a 
feeling  that  the  missile  is  in  motion  over  the  terrain.  The  effectiveness  of  the 
feeling  of  motion  provided  by  a  flight  simulator  can  be  largely  measured  by  two 
criteria:  the  realism  of  the  displayed  scene  and  the  update  rate  of  the  display. 

1.  Realism 

Many  factors  contribute  to  the  perceived  realism  of  a  displayed  natural 
scene.  Early  attempts  to  quantitatively  measure  realism  consisted  of  counting  the 
number  of  “edges”  or  lines  that  a  scene  contained.  This  later  gave  way  to 
counting  the  number  of  “faces”  or  polygons  in  a  scene.  Since  each  polygon  was 
colored  in  a  single  shade,  it  was  felt  that  each  polygon  represented  a  single  “bit” 
of  information  in  the  scene.  Therefore,  the  more  polygons  the  scene  contained, 
the  more  “realistic”  it  was  felt  to  be  [Ref.  5:pp.  27-28]. 

The  latest  advances  in  computer  graphics  have  also  made  * h is  measure  of 
etfecriveness  obsolete.  -V’irh  'he  introduction  of  systems  'hat  are  aide  -o  rill 
polygons  with  textured  patterns,  a  single  polygon  can  now  contain  thousands  of 
“bits”  of  information.  As  a  result,  a  scene  drawn  with  a  few  textured  polygons 
can  appear  more  realistic  than  one  with  an  order  of  magnitude  more  untextured 


ones.  Early  textures  consisted  of  superimposing  things  such  as  mathematical 
noise  functions  or  stripes  on  the  polygons.  More  recent  advances  have  allowed  the 
texture  to  be  derived  from  digital  photographs  of  a  similar  scene.  For  example, 
polygons  representing  a  part  of  terrain  covering  by  meadow  could  be  filled  with  a 
digital  texture  derived  from  an  aerial  photograph  of  a  meadow  [Ref.  5:  p.  28]. 

Since  most  currently  available  graphics  workstations  do  not  support  the 
use  of  texture  filled  polygons,  the  use  of  texture  was  deemed  to  be  outside  the 
scope  of  the  current  project.  Rather,  the  project’s  work  concentrated  on 
determining  how  realistically  a  scene  could  be  rendered  in  real-time  incorporating 
only  the  use  of  lighting  and  shading  models  along  with  terrain  hidden-surface 
algorithms.  These  topics  are  covered  in  more  detail  in  Chapter  V. 

2.  Frame  Update  Speed 

Another  important  aspect  of  a  flight  simulator’s  performance  is  the  speed 
at  which  it  is  capable  of  displaying  successive  frames  in  a  scene.  The  faster  the 
update  rate,  the  more  continuous  the  motion  appears.  As  a  reference,  standard 
motion  picture  film  is  projected  at  a  rate  of  twenty-four  frames  per  second. 
Although  the  IRIS  workstation  is  capable  of  displaying  up  to  sixty  frames  per 
second,  the  amount  of  computation  that  must  he  done  between  successive  frames 
.n  the  simulation  has  limited  the  update  rate  to  an  average  of  three  frames  per 
second.  While  this  presents  a  less  than  smooth  motion,  it  is  felt  to  be  adequate 
for  the  purposes  of  the  prototype. 


C.  ORGANIZATION 


The  above  sections  of  this  chapter  have  provided  background  on  flight 
simulation  in  general,  and  the  missile  whose  flight  is  specifically  being  simulated. 
Chapter  II  provides  an  overview  of  the  hardware  used  in  running  the  simulation. 
The  structure  and  content  of  the  Defense  Mapping  Agency  (DMA)  Digital 
Terrain  Elevation  Data  (DTED)  are  discussed  in  Chapter  III.  Chapter  IV 
discusses  the  motivation  behind  and  creation  of  the  two-dimensional  contour  map 
displays.  Chapter  V  covers  the  storage  and  use  of  the  DMA  DTED  to  produce  a 
lighted  and  shaded  three-dimensional  polygonal  terrain  display.  The  mathematics 
and  process  involved  in  simulating  flight  over  the  terrain  are  detailed  in  Chapter 
VI.  Chapter  VII  discusses  the  creation,  insertion,  animation,  and  designation  of 
targets.  Chapter  VIII  covers  the  creation  and  drawing  of  cultural  features. 
Chapter  IX  contains  a  user’s  guide  for  operation  of  the  FOG-M  simulator. 
Chapter  X  concludes  with  a  discussion  of  limitations,  future  extensions  and 
research  topics,  and  summarizes  the  research  conducted.  Narrative  descriptions  of 
the  modules  and  listings  of  the  program  source  code  for  each  of  the  modules  are 
included  as  Appendices  A  and  B  respectively. 


II.  COMPUTER  SYSTEM 


As  discussed  in  Chapter  I,  flight  simulators  are  nothing  new.  The  significance 
of  this  work  lies  in  the  speed  with  which  it  was  developed,  the  display  rate 
achieved,  and  the  realism  and  fidelity  of  the  display  in  comparison  to  the  cost  of 
the  system  that  supports  it.  This  project  was  technically  feasible  only  because  of 
the  capabilities  and  high  performance  of  the  IRIS  (Integrated  Raster  Imaging 
System)  Turbo  2400  Graphics  Workstation,  manufactured  by  Silicon  Graphics, 
Incorporated.  Others  have  also  used  the  IRIS  as  a  base  on  which  to  build  flight 
simulators  [Ref.  6].  This  low-cost  ($50,000  to  $100,00)  three-dimensional  display 
system  is  summarized  in  Figure  2.1  and  is  discussed  more  fully  below. 

A.  HARDWARE  AND  SYSTEM  OVERVIEW 

The  IRIS  has  a  conventional  Von  Neumann  type  computer  architecture  but 
adds  custom-built  special  purpose  VLSI  circuits  and  a  pipelined  design  to  provide 
the  graphics  functions  that  are  implemented  in  software  on  other  comparably- 
priced  workstations.  Conceptually,  there  three  pipelined  components  in  the  IRIS 
hardware:  rhe  applications /graphics  processor,  rhe  Geometry  Pipeline,  and  the 
raster  subsystem  [Ref.  7:p.  l-l].  The  applications/graphics  processor  is  a 
conventional  Motorola  MC68020  processor  running  at  16.7  MHz.  This  processor 
runs  the  applications  program(s)  within  a  UNIX  System  V  operating  system. 


ETHERNET  to  Vix  and  other  IRIS 


32  bit  18.7  MHz  Motorola  MC68020  CPU 

6  Megabytes  of  CPU  Memory 

32  1024x788  bitplanee  of  Display  Memory 

Hardware  matrix  multiplier  A  floating  point  accelerator 
Hardware  Gouraud  shading,  depth  cueing  A  backface  polygon  removal 

T|| 

12  pipelined  custom  VLSI  Geometry  Engines 
18-bit  Z-buffer  for  Hidden  Surface  Elimination 

2  72  Megabyte  Winchester  Disk  Drives 

60  Hs  non-interlaced  10*  RGB  high  resolution  monitor 
83  key  up-down  encoded  keyboard 

3  button  mouse 

32-button  and  8-dial  valuator  boxes 
Unix  System  V 
Ethernet  to  VAX ' 3 
IRIS  Graphics  Library 


Features  of  the  IRIS  Turbo  2400  Graphics  Workstation 

Figure  2.1 
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Applications  either  issue  graphics  commands  in  immediate  mode ,  in  which  case 
they  are  sent  through  the  Geometry  Pipeline  immediately  as  individual  graphics 
primitives,  or  compile  graphics  commands  into  graphical  objects,  in  which  case 
they  are  sent  through  the  Geometry  Pipeline  as  a  single  geometric  entity  when 
explicitly  called  at  some  later  point  in  time. 

The  Geometry  Pipeline  takes  commands  in  terms  of  the  user’s  world 
coordinates,  performs  specified  matrix  transformations  on  them  using  the  matrix 
multiplier  and  floating  point  accelerator  built  into  the  hardware,  and  then  clips 
and  scales  the  transformed  coordinates  into  screen  coordinates.  The  raster 
subsystem  takes  the  screen  coordinates  output  by  the  Geometry  Pipeline  and 
updates  the  bitplanes  (display  memory)  to  contain  the  lines,  polygons,  or 
characters  specified  by  the  input  coordinates.  The  raster  subsystem  also  performs 
polygon  fill,  shading,  depth-cueing,  and  hidden  surface  removal.  A  conventional 
video  controller  uses  the  values  in  the  bitplanes  and  the  color  tabic  to  produce  an 
image  on  the  monitor. 

B.  SOFTWARE 

The  C  programming  language  is  native  to  UNIX  and  is  the  language  used  for 
ail  of  rhe  IRIS  system  software.  The  IRIS  Graphics  Library,  which  provides  both 
high-  and  low-level  graphics  and  utility  commands,  can  be  called  in  C, 
FORTRAN,  Pascal,  or  LISP.  However,  due  to  the  built-in  bias  of  UNIX  and  the 
IRIS,  plus  the  local  pool  of  knowledge,  the  C  programming  language  was  the 
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pro  forma  choice  for  programming  all  parts  of  the  FOG-M  simulator.  The  IRIS 
User’s  Guide  [Ref.  7]  breaks  the  Graphics  Library  commands  into  the  following 
twelve  categories: 

-  Global  State  commands  initialize  the  hardware  and  control  global  variables, 
and  are  used  mostly  in  FOG-M’s  init_iris  routine. 

-  Drawing  Primitives  are  used  throughout  FOG-M.  They  create  points,  lines, 
polygons,  circles,  arcs,  and  text  strings. 

-  Coordinate  Transformations  specify  mappings  within  and  between  user- 
defined  world  coordinates  and  screen  coordinates.  These  are  used  to  move 
targets  and  to  simulate  Bight. 

-  Drawing  Attribute  commands  specify  textures  and  fonts.  Although  texture 
would  greatly  improve  the  appearance  of  the  terrain,  the  IRIS  provided 
textures  are  applied  in  the  screen  coordinate  system,  so  they  do  not  scale  or 
tilt  to  conform  to  the  terrain,  and  produce  a  very  artificial  result. 

-  Display  Mode  and  Color  commands  determine  how  the  bitplanes  are  used 
and  what  colors  appear  on  the  screen.  These  include  the  commands  that  set 
double-buffering,  establish  writemasks,  and  define  the  color  table. 

-  Inputf  Output  commands  initialize  and  read  the  dials  and  mouse. 

-  Object  Creation  and  Editing  commands  allow  manipulation  of  complex 
displays  as  a  single  entity.  They  are  used  in  all  FOG-M  displays. 

-  Picking  and  Selecting  commands  are  not  used  in  FOG-M. 

-  Geometry  Pipeline  Feedback  commands  are  not  used  in  FOG-M. 

-  Curve  and  Surface  commands  draw  complex  curves  and  smooth  surfaces. 
Experiments  with  these  produced  more  realistic  terrain  images,  but  not  even 
close  to  real-time,  making  flight  animation  impossible. 

-  Shading  and  Depth- cueing  commands  provide  Gouraud  shading  of  polygons 
and  intensities  that  vary  with  distance  from  the  viewer. 

-  Text  port  commands  define  an  area  of  the  screen  for  text.  They  are  not  used 

in  FOG-M. 

Also  available  on  the  system,  and  used  by  FOG-M,  are  the  math  library  with 
sine,  cosine,  arctangent,  hypotenuse,  and  exponentiation  functions,  and  routines 
that  access  the  system  clock  in  order  to  determine  elapsed  time. 
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m.  DIGITAL  ELEVATION  TERRAIN  DATA 

A.  INTRODUCTION 

Unlike  other  flight  simulation  systems,  which  may  rely  on  manual  creation  of 
the  terrain  [Ref.  8],  the  source  data  for  the  terrain  in  the  FOG-M  simulation  is  a 
Defense  Mapping  Agency  (DMA)  digital  terrain  elevation  database  (DTED)  for 
Fort  Hunter-Liggett,  California.  The  database  is  not  Level  1  DTED,  but  rather  a 
DMA  special  product  produced  about  1980  at  a  higher  resolution  than  normal 
Level  1  DTED  [Ref.  9).  Level  1  DMA  data  contains  elevation  points  spaced  at 
three  arc-second  intervals,  or  approximately  every  one  hundred  meters.  The  Fort 
Hunter-Liggett  special  data  contains  points  at  twelve  and  one-half  meter  spacing, 
which  is  eight  times  the  resolution  of  Level  1  data. 

B.  COVERAGE 

The  area  covered  by  the  database  is  thirty-six  kilometers  wide  and  thirty-five 
kilometers  high,  with  6400  data  points  per  square  kilometer.  This  area  includes 
most  of  Fort  Hunter-Liggett  plus  some  surrounding  land,  and  is  bounded  by 
latitudes  36°  05'  00"  i to  the  north)  and  35°  50' 00"  (south)  and  longitudes 
121°  04'  30"  (east)  and  121°  20'  30"  (west).  In  terms  of  Universal  Transverse 
Mercator  (UTM)  coordinates,  the  area  has  easting  (A)  of  10SFQ41000  to 
10SFQ77000  and  northing  ( F)  of  10SFQ60000  to  10SFQ95000.  The  database 
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appears  to  be  based  on  DMA  forty  foot  interval  contour  map  products,  because 
peaks  tend  to  have  flattened  tops.  This  was  confirmed  both  by  a  comparison  of 
surveyed  instrumentation  sites  on  or  near  peaks  with  their  digital  terrain  values 
[Ref.  10:  pp.  1-2],  and  by  a  Bezier  surface  patch  image  of  the  data  created  locally. 

C.  STRUCTURE 

The  data  is  stored  in  an  unformatted  sequential  file  that  is  organized  as  a 
stream  of  integers.  Each  integer  (sixteen  bits)  represents  both  the  vegetation  code 

and  bald  terrain  elevation  in  feet  at  one  sampling  point,  as  illustrated  in  Figure 

3.1  below. 


Veg.  Code 

Bald  Terrain  Elevation 

bit: 

15  14  13 

12  11  10  9876543210 

Figure  3.1  DTED  Data  Encoding 

The  thirteen  low-order  (rightmost)  bits  contain  the  elevation,  allowing  a  range 
from  zero  *o  b  10 L  feet,  although  rhe  highest  point  in  the  database  is  3744  feet. 
The  three  high-order  (leftmost)  bits  specify  one  of  eight  vegetation  codes,  which 
are  given  in  Table  3.1  below.  Vegetation  codes  are  only  available  for  points 
within  the  boundaries  of  Fort  Hunter-Liggett  proper.  The  file  is  written  one 


TABLE  3.1  DTED  VEGETATION  CODES 


Code 

Description 

0 

Less  than  one  meter 

1 

One  to  four  meters 

0 

Four  to  eight  meters 

3 

Eight  to  twelve  meters 

4 

Twelve  to  twenty  meters 

5 

Greater  than  twenty  meters 

6 

No  data  available 

7 

Unused 

square  kilometer  at  a  time,  beginning  with  the  lower  left  one  kilometer  grid  square 
(41.60),  proceeding  up  the  column  to  the  upper  left  grid  square  (41.94),  then 
doing  the  next  column  from  bottom  to  top  (42,60  to  42,94)  and  so  on;  the  upper 
right  one  kilometer  grid  square  (76,94)  is  the  last  one  written.  Within  each  one 
kilometer  grid  square,  the  individual  data  points  are  written  in  the  same  pattern, 
beginning  with  the  lower  left,  doing  each  column  from  bottom  to  top,  and  doing 
the  columns  from  left  to  right.  This  file  layout  is  summarized  in  Figure  3.2.  The 
position  in  the  file  of  the  elevation  for  a  point  expressed  in  five  digit  local  UTM  X 
and  Y  coordinates  is  found  as  shown  in  Equation  3.1. 

position  =  35  *  {integer (A/ 1000)  -  41)  +  [integer  (  Yf 1000)  -  59)  (3.1) 

D.  LOCATION 

The  complete  DTED  file  occupies  16,128,000  bytes  of  storage.  Due  to  a  local 
shortage  of  available  disk  space,  this  file  must  permanently  reside  on  the  UNIX 
VAX  11/785  system  rather  than  on  the  IRIS  system.  The  FOG-M  simulator 


presently  operates  on  a  ten  kilometer  square  extract  from  this  database.  A 
program  on  the  VAX  called  make— database— e  allows  interactive  specification 
of  the  area  and  resolution  desired,  and  produces  an  extract.  This  extract  is  sent 
over  the  Ethernet  to  the  IRIS  to  serve  as  the  input  for  a  FOG-M  run.  However,  if 
the  data  is  sent  directly,  it  is  received  with  each  pair  of  bytes  swapped ,  so  another 
program,  swapdma,  is  run  on  the  VAX  before  transmittal.  This  program  swaps 
the  low-  and  high-order  bytes  of  each  integer  so  that  the  swapping  during 
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transmission  is  cancelled. 
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IV.  TWO-DIMENSIONAL  TERRAIN  MAP  PORTRAYAL 


The  two-dimensional  representation  of  the  terrain  was  begun  as  the  first 


graphics  portion  of  the  system,  in  order  to  gain  familiarity  with  the  IRIS  graphics 


workstation  and  the  Defense  Mapping  Agency  (DMA)  digital  terrain  elevation 


data  (DTED).  Contour  maps  are  the  traditional  approach  to  two-dimensional 


terrain  portrayal,  and  thus  were  the  basis  for  the  two-dimensional  images  of  the 


terrain  generated  here  (Figure  4.1).  Although  these  two-dimensional  images  are 


not  "rue  contour  maps,  "hey  are  still  referred  to  as  such  in  this  study  because  of 


their  close  relation  and  common  origin.  The  algorithms  for  determining  and 


drawing  the  forty  foot  contour  lines  found  on  a  normal  contour  map  seemed  non¬ 


trivial,  so  a  simpler  alternative  was  chosen.  Each  elevation  datum  is  represented 


by  a  tile ,  with  the  implicit  X  and  Z  (easting  and  northing,  respectively) 


coordinates  of  the  elevation  datum  being  the  center  of  the  tile. 


A.  COLORS 


The  color  of  a  tile  is  determined  by  its  vegetation  code,  and  its  intensity  (or 


•  muling  i  by  .ts  •devanon.  The  nrenr  was  *o  use  green  for  ‘lies  with  vegetation 


and  brown  for  tiles  without  vegetation.  However,  the  DTED  vegetation  codes 


lump  together  both  “no  vegetation”  and  “vegetation  less  than  one  meter  high.” 


Brown  dies  thus  include  both  unvegetated  areas  (e.g.  rock  slabs,  areas  above  the 
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Figure  4.1  Simulator  Contour  Map  Display 


treeline)  and  grasslands  or  meadows.  This  is  significant  in  the  Fort  Hunter- 
Liggett  area,  because  most  of  the  valleys  are  covered  in  grass,  and  all  of  the  high 
ground  is  below  the  treeline.  The  result  is  a  map  with  brown  valleys  and  green 
ridgelines.  While  this  was  readily  accepted  as  natural  by  most  viewers,  pilots 
with  a  background  in  low-level  flight  found  it  awkward,  and  contrary  to  their 
expectations  (from  flight  charts)  of  green  valleys  and  brown  mountains.  While 
this  might  be  significant  in  other  flight  simulation  applications  (particularly  those 
designed  for  pilots),  the  initial  representation  was  deemed  most  appropriate  for 
the  target  audience  of  the  FOG-M  simulator. 

A  similar  initial,  intuitive  choice  was  made  for  the  elevation-keyed  shading. 
High  intensity  (light)  colors  were  used  for  higher  elevations,  and  low  intensity 
(dark)  colors  for  lower  elevations.  This  was  accepted  as  natural  by  almost  all 
viewers.  The  optimum  number  of  intensities  (shadings)  to  use  in  the  map  was 
experimentally  determined  to  be  sixteen.  A  small  power  of  two  was  desirable  due 
to  the  nature  of  the  writemasks  used  to  improve  display  speed.  A  large  number  of 
colors  provides  greater  elevation  definition  and  prevents  large  masses  of  the  same 
color  in  areas  where  elevations  change  gradually.  However,  having  too  many 
colors  destroys  rhe  contour-man  effect,  since  adjacent  colors  are  so  \0se  *hat  no 
boundary  distinguishaoie  between  them.  Eight  -.hades  cacti  m  green  .mo  r  >w;i 
were  used  initially.  The  shift  to  sixteen  shades  of  each  produces  a  better  looking 
map.  Due  to  the  RGB  (red.  green,  blue)  nature  of  color  creation  on  the  IRIS,  the 


greens  were  still  barely  differentiable  at  thirty-two  shades,  but  the  browns  (a 


combination  of  mostly  red,  some  green,  and,  in  some  shades,  a  trace  of  blue) 
began  to  blend  together. 

To  determine  the  elevations  at  which  color  shades  should  change  (in  order  to 
use  the  full  range  of  shades),  the  maximum  and  minimum  elevations  of  the 
terrain  section  in  use  must  be  known.  Rather  than  preprocess  the  data  before  each 
run,  these  values  are  coded  as  constants  in  a  header  file.  The  equation  for  which 
color  index  to  use  is  straightforward  (see  Equation  4.1)  but  takes  significant  time 
when  repeated  ten  thousand  times. 

elevation— MIN 

index  =  base  index  +  -  *  #  of  shades  (4.1) 

MAX-MIN  ~  ~ 

Therefore,  the  fifteen  points  at  which  the  shade  changes  are  precalculated  and 
stored  in  an  array  so  that  no  calculations  are  needed  at  each  point,  just  an  array 
lookup. 

B.  DRAWING 

The  map  can  then  be  produced  by  determining  the  color  and  shade  for  each 
tile,  and  drawing  it  as  a  filled  square.  However,  an  increase  in  speed  can  be  gained 
by  exploiting  the  structure  of  the  data  and  the  line  drawing  hardware  of  the  IRIS. 
The  data  is  snil  processed  a  point  at  a  rime  within  each  one  kilometer  column, 
but  no  drawing  is  done  until  an  elevation/shading  breakpoint  is  reached.  Then  a 
single  line  of  one  tile’s  width  is  drawn  to  color  all  tiles  since  the  previous  elevation 


breakpoint. 
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C.  WRITEMASKS 

A  more  significant  speed  improvement  (on  the  order  of  fifty  per  cent  more 
frames  per  second)  was  achieved  with  writemasks.  Writemasks  are  a  relatively 
low-level  hardware  feature  that  can  be  used  for  many  purposes.  In  the  FOG-M 
simulator,  they  are  used  to  prevent  the  contour  map  from  being  overwritten. 
This  allows  the  map  to  be  drawn  only  once  into  the  bitplanes,  and  have  it  remain 
on  the  screen  without  being  re-drawn  during  each  frame  update.  In  order  to 
under  tand  how  writemasks  work,  one  must  understand  the  layout  and  use  of  the 
IRIS’s  color  table  and  bitplanes. 

1.  Color  Table 

The  color  table  associates  a  particular  binary  number  with  a  color. 
When  the  display  system  asks  what  color  some  number  is,  the  color  table  replies 
with  the  intensities  for  the  red,  green  and  blue  color  guns  that  will  produce  the 
color  defined  for  the  input  number.  This  input  number  is  referred  to  as  a 
colorindcx.  Thus  the  color  displayed  on  the  screen  depends  on  the  colorindex 
associated  with  a  given  pixel,  and  the  color  associated  with  that  colorindex  in  the 
color  table.  Table  4.1  gives  the  color  table  entries  that  are  the  defaults  on  the 
IRIS  workstation. 

2.  Bitplanes 

The  colorindex  that  is  associated  with  each  pixel  is  stored  in  the  display 

memory,  which  is  composed  of  bitplanes.  Each  bitplane  has  one  bit  for  each  pixel 

on  the  display  screen,  so  a  bitplane  is  1024  bits  wide,  768  bits  high  and  one  bit 
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TABLE  4.1  IRIS  DEFAULT  COLORINDEX  DEFINITIONS 


Color 

Colorindex 

Decimal 

Binary 

0000000000000000  ! 

0000000000000001 

0000000000000010 

Yellow 

0000000000000011 

Blue 

0000000000000100 

Magenta 

5 

0000000000000101 

Cyan 

6 

0000000000000110 

White 

7 

0000000000000111 

deep.  When  used  in  double  —  buf f er  mode  (as  in  FOG-M),  the  IRIS  uses  sixteen 
bitplanes  (numbered  0  to  15)  for  each  buffer.  The  frontbuffer  is  the  one  whose 
binary  contents  define  the  image  being  displayed.  While  the  frontbuffer  is  being 
displayed,  the  next  image  is  created  by  issuing  drawing  commands  which  affect 
only  the  backbuffer.  Once  a  new  image  is  completed  in  the  backbuffer,  the 
buffers  are  swapped,  so  the  backbuffer  becomes  the  frontbuffer  and  is  displayed. 
The  old  frontbuffer  becomes  the  backbuffer,  and  is  then  available  for  update. 

3.  Writemask  Example 

Consider  the  pixel  at  location  (0,0)  -  the  lower  left  corner  of  the  screen. 
The  colorindex  of  that  pixel  is  determined  by  sixteen  bits:  one  from  the  lower  left 
corner  of  each  bitpiane.  The  dispiav  system  reads  those  sixteen  bits  as  a  binary 
number  (the  colorindex),  and  uses  the  color  table  to  determine  what  color  to 
make  that  pixel.  For  example,  using  the  default  colors  defined  in  Table  4.1  above, 
that  pixel  will  be  colored  black  if  all  sixteen  bitplanes  have  zeroes  in  their  lower- 


left  corners,  since  the  value  of  the  sixteen  bit  binary  number  00000000000000002  is 
zero.  If  the  current  color  is  set  to  magenta  (color  five,  whose  binary  value  has  ones 
in  bits  zero  and  two)  and  a  drawing  command  is  issued,  bitplanes  zero  and  two 
afe  set  to  one,  and  all  other  bitplanes  are  set  to  zero,  for  every  pixel  covered  by 
the  drawing  command.  These  pixels  will  now  be  displayed  as  magenta,  because 
the  colorindex  constructed  from  the  sixteen  bitplanes  will  be  000000000000010 12 
(510),  and  the  color  table  tells  the  display  system  that  color  5J0  is  magenta. 

The  previous  example  showed  that  a  drawing  command  works  by 
placing  ones  in  certain  bitplanes,  and  zeroes  in  all  of  the  rest,  with  the  current 
color  specifying  which  bitplanes  get  which.  A  writemask  tells  each  bitplane  to 
either  allow  or  ignore  the  changes  a  drawing  command  says  to  make.  In  normal 
double-buffered  usage,  the  writemask  is  11111111111111112,  meaning  all  sixteen 
bitplanes  should  allow  updates.  Now  suppose  there  is  an  image  on  the  screen 
which  uses  just  the  default  eight  colors.  Bitplanes  three  through  fifteen  are  all 
zeroes,  because  all  of  the  colors  have  colorindices  with  three  or  less  binary  digits, 
which  will  be  in  bitplanes  zero,  one,  and  two.  If  the  writemask  is  changed  to 
11I11111111110002  after  drawing  the  image,  those  lower  three  bitplanes  are 
"frozen'  and  will  nor  be  '’hanged  bv  any  drawing  '-ommand.  Setting  rhe  color  'o 
black  and  clearing  the  screen  will  not  change  anything.  The  upper  bitpianes  will 
be  set  to  all  zeroes,  which  they  already  were.  The  lower  three  bitplanes  will  be 
told  to  reset  to  zero,  but  will  not  do  it  because  they  are  protected  by  the 


writemask. 


Now  suppose  you  want  to  draw  a  grey  line  on  top  of  the  image.  The  line 
only  needs  one  color,  so  it  can  be  drawn  in  one  bitplane.  (Two  bitplanes  will  allow 
three  more  colors  on  top  of  the  map,  three  bitplanes  allow  seven,  etc.)  The  first 
“free”  bitplane  is  number  three.  Turning  on  a  bit  in  this  plane  (and  not  turning 
on  any  bits  in  higher  planes)  requires  a  colorindex  in  the  range  10002  to  1 1 112  (8]0 
to  1510).  Defining  color  eight  in  the  color  table  as  grey,  making  color  eight  the 
current  color,  and  then  drawing  the  line  is  sufficient  to  get  the  image  into  the 
bitplanes,  but  the  display  will  not  show  the  desired  effect.  If  the  image 
underneath  the  line  is  black  (i.e.  bitplanes  zero  through  two  are  all  zeroes  form 
some  pixels),  the  line  will  appear  grey,  as  intended,  for  those  pixels.  However,  if 
the  image  underneath  the  line  is  red  (i.e.  the  lower  bitplanes  contain  0012),  the 
composite  colorindex  retrieved  by  the  display  system  is  0000000000001 00 12  or  9J0) 
and  since  color  nine  is  not  defined  in  the  color  table,  it  appears  as  black.  Thus 
every  colorindex  that  has  bit  three  (because  the  line  is  in  bitplane  3)  set  to  one 
(i.e.  colorindices  10002  to  11112,  or  810  to  15l0)  must  be  defined  as  grey  in  order  to 
produce  the  desired  image. 

4.  Writemasks  in  FOG-M 

The  map  image  used  in  FOG-M  is  stored  in  the  first  six  bitplanes 
(numoered  0  througn  5)  of  Doth  burfers,  which  means  sixty-four  colors  are 
available:  eight  are  the  IRIS  defaults,  sixteen  are  shades  of  brown,  sixteen  are 
shades  of  green,  and  twenty-four  are  unused.  The  writemask  defined  as 

SAVEMAP  (C016  or  00000000 110000002)  allows  things  to  be  drawn  on  top  of  the 
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map  in  bitplanes  six  and  seven.  Colorindices  64  through  127  are  all  defined  as 
blue  in  the  color  table,  so  anything  drawn  in  bitplane  six  appears  on  top  of  the 
map  in  blue.  Similarly,  bitplane  seven  is  used  for  red.  with  colorindices  128 
through  255  all  correspondingly  defined  to  be  red. 

The  speed  improvement  due  to  writemasks  in  FOG-M  comes  from  not 
having  to  re-draw  the  map  each  time  the  screen  is  updated.  The  cost  is  the  use  of 
many  more  indices  in  the  color  table,  which  limits  the  number  of  colors  available 
for  use  on  top  of  the  map.  For  our  simulation  system,  with  only  two  colors 
needed  on  top  of  the  map,  there  is  plenty  of  room  in  the  color  table.  Therefore, 
the  gain  in  speed  comes  at  no  real  cost. 


V.  THREE-DIMENSIONAL  TERRAIN  CONSTRUCTION 


A.  REPRESENTATION  DECISIONS 
1.  Polygons  versus  Patches 

Early  experiments  in  the  study  involved  attempting  to  display  the 
terrain  using  parametric  bi-cubic  surface  patches.  A  surface  patch  is  simply  a 
smooth  curved  surface  fitted  to  a  set  of  data  points.  A  discussion  of  the  theory 
and  use  of  surface  patches  can  be  found  in  the  IRIS  User’s  Guide  [Ref.  7:sec.  11-3] 
and  Hearn  and  Baker  [Ref.  lltpp.  193-2051.  It  was  quickly  determined  that  it 
would  not  be  possible  to  use  surface  patches  to  represent  the  terrain  and  still 
maintain  a  real-time  update  of  the  terrain  during  flight. 

An  alternate  method  of  displaying  a  three-dimensional  object  is  through 
the  use  of  a  set  of  planar  polygon  surfaces  that  join  at  common  edges  to  form  the 
terrain  object.  This  method  has  the  advantage  of  being  much  simpler,  and 
therefore  faster,  to  generate  and  display.  For  this  reason  it  was  chosen  for  use  in 
the  project. 

Figure  5.1  shows  ‘he  method  of  constructing  the  terrain,  surface  is  a  set 

of  triangles.  The  term  gridsquare  is  used  in  the  remainder  of  the  chapter  to  refer 
to  a  set  of  two  triangles  with  a  common  hypotenuse  that  form  a  square  of  the 


terrain  grid. 


2.  Resolution 


The  special  DMA  data  file  used  in  this  project  contains  elevation  data 
that  is  spaced  at  a  twelve  and  one-half  meter  interval.  One  of  the  first  questions 
which  had  to  be  answered  concerning  the  three-dimensional  portrayal  of  this  data 
was,  “In  how  fine  a  resolution  can  the  data  be  displayed,  while  still  allowing  for  a 
sufficient  frame  update  speed?”  Early  test  runs  showed  that  using  the  full  twelve 
and  one-half  meter  resolution  would  be  much  too  slow,  although  it  provided  an 
excellent  representation  of  the  terrain.  An  adequate  frame  update  rate 
(approximately  three  to  four  frames  per  second)  was  achieved  with  a  seventy-five 
meter  resolution  or  every  sixth  data  point.  Since  this  was  an  early  test,  displaying 
terrain  without  any  targets  or  cultural  features,  a  one  hundred  meter  resolution 
was  decided  upon  for  use  in  the  remainder  of  the  project.  This  allowed  for  an 
adequate  “cushion”  of  processing  time  to  complete  the  additional  computations 
that  would  be  needed  in  the  final  product,  while  still  providing  an  adequate 
degree  of  resolution. 

3.  Elevation  Scaling 

After  viewing  the  early  representations  of  the  terrain,  it  appeared  that 
'he  hills  did  not  give  an  appropriate  appearance  of  height.  Although  this  was  a 
subjective  judgement,  it  was  shared  by  most  people  who  viewed  the  display  and 
compared  it  to  aerial  photographs  of  the  area.  Because  of  this,  it  was  decided  to 
scale  the  elevations  of  the  displayed  points  upward  Two  approaches,  linear 
scaling  and  exponential  scaling,  were  examined. 


In  the  linear  scaling  approach,  each  elevation  point  was  simply 


multiplied  by  a  scale  factor  as  shown  in  Equation  5.1. 


Elev  =  <7 

n.ew 
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old 


(5.1) 


Using  this  approach,  it  appeared  that  a  scaling  factor  between  1.5  and  2.0  was 
necessary  to  achieve  the  desired  effect. 

In  the  exponential  approach,  the  elevation  of  each  point  was  raised  to  a 
fixed  power  as  shown  in  Equation  5.2. 


El  e  v 


riew 


El  tv 


old 


(5.2) 


This  approach  has  the  effect  of  exaggerating  the  higher  elevations  to  a  greater 
degree  than  the  lower  ones.  It  was  chosen  as  the  approach  for  use  in  the  project 
based  on  subjective  observations  of  the  displays  produced  by  the  two  methods. 
The  scaling  factor,  a,  was  chosen  as  1.05.  Using  this  factor  produces  the 
equivalent  of  a  linear  scaling  of  1.5  for  the  maximum  elevation  and  1.4  for  the 
minimum  elevation  contained  in  our  area  of  interest. 

Subsequent  to  the  decision  to  use  an  exaggerated  elevation  scale, 
research  results  were  discovered  which  supported  it.  In  a  study  conducted  by  the 
U.S.  Army  Research  Institute  for  the  Behavioral  and  Social  Sciences,  observers 
were  asked  to  pick  a  computer  generated  line  drawing  that  best  matched  actual 
terrain.  The  line  drawings  had  different  exaggerations  of  the  vertical  (elevation) 
scale.  The  overall  ratios  chosen  by  the  four  observers  ranged  from  1.25:1  to 


1.50:1.  The  drawings  presented  to  the  observers  had  exaggeration  ratios  ranging 
from  1:1  to  1.75:1.  [Ref.  12] 

4.  Shading  and  Texturing 

As  explained  above,  each  one  hundred  meter  square  of  the  terrain,  a 
“gridsquare,”  is  represented  by  two  triangles  in  three-space  that  share  a  common 
diagonal  edge.  The  process  of  applying  colors  to  these  polygons,  shading ,  was  the 
next  area  of  research  in  the  project. 

a.  Elevation  Based  Shading 

Three  different  shading  algorithms  were  investigated.  The  first  was 
a  simple  algorithm  where  the  shade  of  a  polygon  was  a  function  of  its  elevation. 
Higher  elevations  are  shaded  in  lighter  shades  of  green  while  lower  elevations 
receive  darker  shades.  Equation  5.3  represents  the  assignment  of  a  shade  from  the 
color  map. 

elev  -  Min  Elev 

color  index  =  base  index  +  - - -  *  #  of  shades  (5.3) 

Max  Elev  -  Min  JElev 

The  darkest  green  is  stored  in  the  base  index  color  map  location  and  the  lightest 
green  in  the  baseindex  +  #  o/  shades  location.  Although  this  approach  works 
well  for  two-dimensional  contour  maps  fsee  Chapter  IV).  and  is  currently  used  in 
another  "low  cost  "  simulator  Ref.  dt.  it  did  nor.  appear  to  present  a  realistic  view 
of  the  terrain.  An  advantage  of  this  approach,  however,  is  that  the  calculation  of 
the  color  index  is  simple  enough  to  be  done  with  no  preprocessing. 


b.  Lambert’s  Cosine  Law  Shading 


The  second  method  of  determining  the  shade  for  a  polygon  involved 
the  use  of  a  point  light  source  and  Lambert’s  cosine  law  [Ref.  ll:p.  278],  Let  N 
be  a  unit  normal  vector  to  the  polygon,  and  L  be  a  unit  vector  in  the  direction  of 
the  light  source.  The  angle  between  N  and  L ,  $,  is  the  angle  of  incidence. 
Lambert’s  Law  states  that  the  intensity  of  the  light  reflected  from  the  polygon  is 
proportional  to  cos  $  (Equation  5.4). 

I  ct  cos  $  (5.4) 


In  order  to  use  this  law,  the  normal  vector  (iV),  the  light  source  vector  (L),  and 
the  angie  between  them  (<$)  must  be  known.  .V  can  be  determined  by  taking  the 
cross  product  of  el  and  e2,  where  el  is  a  unit  vector  in  the  direction  from  vertex 
B  to  vertex  C  of  the  polygon,  and  v2  is  a  unit  vector  in  the  direction  from  vertex 
B  to  vertex  A  of  the  polygon  (Equation  5.5  and  Figure  5.2). 

Ar  =  el  *  v2  (5.5) 


With  N  and  L  available,  cos  $  can  be  computed  as  their  dot  product  (Equation 


5.7). 


cos  <l>  —  V  L 


(5.7^ 


Since  the  intensity  is  proportional  to  cos  4>,  the  appropriate  color  index  to  use  can 
be  computed  as 


color  index  =  min  index  *  (4  shades* cos  $) 


(5.8) 


where  min  index  is  the  color  index  of  the  lowest  intensity  green  and 
min  index  -+■  #  shades  is  the  color  index  of  the  highest  intensity  green 
c.  Gouraud  Shading 

The  final  shading  model  investigated  involved  the  use  of  Gouraud 
shading.  The  purpose  of  Gouraud  shading  is  ter  provide  a  continuous  transition  of 
shades  across  a  polygon  so  that  the  shades  at  the  edges  of  adjoining  polygons 
match.  This  in  effect  eliminates  the  visible  boundary  between  polygons  and 
provides  a  smooth  continuous  surface.  The  Gouraud  algorithm  involves 
interpolating  to  determine  the  intensity  to  be  used  at  each  pixel  along  a  scan  line, 
and  is  illustrated  in  Figure  5.3  as  reproduced  from  Hearn  and  Baker  Ref  li  p 
290).  To  use  the  algorithm,  intensity  values  for  each  vertex  of  the  polygon  must 
be  known.  In  the  project’s  implementation,  the  intensity  at  each  vertex  was 
computed  as  the  average  of  the  intensity  values  for  all  the  polygons  meeting  at 
that  vertex,  where  the  individual  polygon's  intensity  values  were  calculated  using 
Lambert’s  cosine  law. 

The  use  of  this  model  posed  two  problems.  First,  even  though  the 
IRIS  supports  Gouraud  shading  in  its  graphics  library,  its  use  increased  the  tune 
between  frames  -o  an  inacceorable  rate  bmproximateiv  one  me  me-haif  ’<>  *hree 
seconds  :>erwe**n  rramesj.  'econo,  'he  -mooming  of  ';ie  iigori'nrn  vorKeu  •  ><> 
well,  resulting  in  terrain  displays  that  lacked  the  necessary  position  cues  to  detect 
motion.  This  second  problem  could  be  alleviated  by  adding  artificial  texture  to 
the  terrain  but  in  light  of  the  speed  problem  it  was  not  pursued  further. 
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For  interpolated  shading,  the  intensity  value 
at  point  4  is  determined  from  intensity  values 
at  points  1  and  2,  intensity  at  point  6  is 
determined  from  values  at  points  2  and  3.  and 

intensities  i*  jther  oomts  •  sucn  is  S'  along 
tne  scan  l*ne  are  mt-erpoiatea  netween  t.he 

values  at  points  4  and  6. 

Figure  5.3  The  Gouraud  Shading  Algorithm 


d.  Adding  Texture 

Lambert’s  cosine  law  was  chosen  as  the  shading  model  for  use  in  the 
project,  providing  the  most  realistic  display  within  the  allowed  computation  time 
constraints.  However,  a  problem  with  its  use  is  that  the  flat  valleys,  with  little 
variance  in  the  surface  normals  of  their  polygons,  produce  large  geographic  areas 
having  a  near  constant  shade.  This  results  in  a  lack  of  motion  cues  in  these  areas 
similar  to  that  experienced  with  the  Gouraud  shading  model.  To  remedy  this 
situation,  a  simple  artificial  texture,  in  the  form  of  a  checker  board,  was  imposed 
on  the  terrain.  The  checker  board  effect  was  implemented  as  follows.  First,  the 
shades  for  the  two  triangles  in  each  gridsquare  were  averaged,  and  this  average 
shade  was  used  for  both  of  them.  This  of  course  causes  the  visible  boundary 
between  the  triangles  to  disappear  leaving  a  square  shaded  in  a  single  color. 
Second,  two  slightly  offset  color  ramps  were  used  with  adjacent  grid  squares  using 
different  ramps  to  compute  their  shades.  One  ramp  is  composed  of  green 
intensities  ranging  from  255  to  50,  while  the  other  uses  intensities  ranging  from 
245  to  40.  *  This  causes  the  shades  for  two  adjacent  gridsquares  with  identical 
surface  normals  to  vary,  providing  the  necessary  texturing. 


*  A  value  of  255  is  the  highest  intensity  green  obtainable,  a  value  of  zero  indicates  the  absence 
of  the  color  green. 
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B.  INTERNAL  DATA  STRUCTURES 

Two  global  arrays  are  maintained  which  store  the  information  necessary  to 
display  the  terrain.  The  first  is  a  five-dimensional  array,  savetrianglc .  that  stores 
the  values  of  the  coordinates  for  each  triangle  making  up  the  terrain  structure. 
The  second  is  a  two-dimensional  array  savecolor  that  stores  the  color  map  indices 
for  each  of  the  terrain’s  grid  squares.  The  purpose  and  range  of  each  of 
savetrianglt's  indices  is  shown  in  Table  5.1.  For  example, 
savetriangle  [3]  [5]  [l]  [l]  [2]  would  contain  the  value  of  the  Y  coordinate  (fifth 
dimension  =  2),  of  the  second  vertex  (fourth  dimension  =  1),  of  the  northern 
triangle  (third  dimension  =  l),  of  the  grid  square  with  X  index  five  and  Z  index 
three  (second  dimension  =  five  and  first  dimension  =  three) . 


TABLE  5.1  LAYOUT  OF  THE  SAVETRIANGLE  ARRAY 


Dimension 

Index  Range 

Purpose 

Start 

End 

First 

0 

98 

Grid  square  index  in  the  Z  direction.  0 
is  the  southern  most  square,  98  is  the 
northern  most. 

Second 

0 

98 

Grid  square  index  in  the  X  direction.  0 
is  the  western  most,  98  is  the  eastern 
most. 

Third 

0 

1 

Triangle  identifier  within  a  grid  square. 

0  is  the  southern  triangle.  1  is  the 
northern. 

Fourth 

0 

O 

Vertex  number  of  the  triangle.  0  is  the 
first  vertex,  2  is  the  last. 

Fifth 

0 

2 

Coordinate  identifier  of  the  vertex.  0  is 
the  X  coordinate,  1  the  Y  coordinate 
and  2  the  Z  coordinate. 

44 


Table  5.2  lists  the  purpose  and  ranges  of  each  of  savecolor’ s  indices.  For 


example,  aat;eco/or[30][l0]  contains  the  color  map  index  to  be  used  for  the  grid 
square  with  a  Z  index  of  thirty  and  an  X  index  of  ten. 


TABLE  5.2  LAYOUT  OF  THE  SA  VECOLOR  ARRAY 


Dimension 

Index  ! 

Start 

lange 

End 

Purpose  ; 

First 

0 

98 

Grid  square  index  in  the  Z  direction.  0 
is  the  southern  most  square,  98  is  the 
northern  most. 

Second 

0 

98 

Grid  square  index  in  the  X  direction.  0 
is  the  western  most.  98  is  the  eastern 
most.  | 

These  two  arrays  contain  all  the  information  necessary  to  construct  an  image 
of  the  terrain.  The  following  chapter  provides  the  details  of  using  their  data  to 
create  a  real-time,  updated  image  of  the  terrain  as  it  is  seen  from  the  FOG-M’s 


camera. 


VI.  FLIGHT  SIMULATION 


A.  OVERVIEW 

The  previous  chapter  discussed  the  methodology  of  constructing  the  three- 
dimensional  terrain  from  the  provided  elevation  data.  This  chapter’s  purpose  is 
to  explain  the  details  of  displaying  this  terrain  in  real  time  as  it  is  seen  through 
the  missile’s  camera. 

The  high  level  pseudocode  for  the  main  program’s  terrain  display  loop  is 
shown  in  Figure  6.1.  Chapter  VII  explains  the  details  of  step  two.  The  details  of 
steps  one  and  six  are  explained  in  Appendix  B  under  the  procedures  rtadcontrols 
(for  step  one)  and  edit  navbox  and  cditindbox  (for  step  two).  The  remainder  of 
this  chapter  discusses  the  details,  considerations,  and  results  of  implementing 
steps  three  through  five. 

B.  UPDATING  THE  MISSILE’S  POSITION 

Determining  the  missile’s  new  position  can  be  broken  into  two  cases: 

[l]  the  missile  is  under  operator  control  and  its  new  position  is  a  function  of  the 
old  position,  the  commanded  direction  of  flight,  the  commanded  altitude, 
and  *he  commanded  speed. 

(2j  the  missile  is  locked  onto  a  target  and  us  new  position  is  a  function  of  its  oid 

position,  the  position  of  the  desired  target,  and  the  commanded  speed. 

In  both  cases,  a  very  large  simplifying  assumption  is  made  to  ignore  the 
dynamics  of  the  missile’s  flight.  This  means  that  the  missile  is  able  to 


While  missile  is  flying  do 

1)  Read  the  values  from  the  operator's  controls 

2)  Determine  new  positions  for  all  the  targets 

3)  Determine  the  new  position  for  the  missile 

4)  Determine  the  position  of  where  the  camera  is  looking 

5)  Display  the  terrain  as  seen  by  the  camera 

6)  Update  the  operator's  control  indicators 


End  while 


Figure  6.1  Main  Display  Loop  Pseudocode 


instantaneously  change  heading,  speed,  and  altitude.  This  assumption  was  made 
only  because  of  development  time  constraints.  It  is  felt  that  the  computations 
necessary  to  more  realistically  model  the  dynamics  of  the  flight  can  be  done 
without  a  serious  degradation  of  the  simulator’s  performance. 

1.  Case  1  -  Operator  Control 

Under  this  case  the  missile’s  X,Y,  and  Z  coordinates  are  computed  as 


'hown  leiovv. 


ADist  =  Speed* A  Time 


,/  ,  •  .  *  ,  -  .  •  c-ww--.  V. 


Where 


-  A Dxst  is  the  distance  traveled  over  the  ground  since  the  last  position  was 
calculated. 

-  Speed  is  the  missile’s  speed  in  feet  per  second  and 

-  A  Time  is  the  elapsed  time  since  the  last  position  was  calculated 

Having  calculated  the  distance  the  missile  must  move  during  this  frame  the 
missile’s  new  coordinates  ( MX,MY,MZ )  can  be  calculated  as 

MXnew  =  MX0ld  +  [cos(Dircmd)  *A Diet]  (6.2) 

MZnew  =  MZold~{3{Tl(Dircmd)  *ADist\  (M 

MY".  -  (Altcmdf  (6-4) 

Where 

-  Dircmd  is  the  commanded  heading  in  radians 

-  Altcmd  is  the  commanded  altitude  in  feet 

-  a  is  the  altitude  scaling  factor  (see  Chapter  V,  Section  A. 3). 

2.  Case  2  -  Locked  Onto  a  Target 

In  the  case  where  the  missile  is  locked  onto  a  target,  the  missile’s  new 
position  is  computed  as  follows.  A Dist  is  computed  as  in  Equation  6.1.  Next  the 
missile’s  heading  is  computed  so  as  to  steer  it  directly  toward  the  target’s 

Dr ir>9t  -  iirr.tan.2i  -\TZ  -  \1Z\.\TX  -  MX'-)  :6.5i 


position: 


-  Dir^  is  the  direction  from  the  missile's  position  to  the  target’s  position 

-  TX  is  the  X  coordinate  of  the  target’s  position 

-  TZ  is  the  Z  coordinate  of  the  target's  position 

-  MX  is  the  X  coordinate  of  the  missile’s  position 

-  MZ  is  the  Z  coordinate  of  the  missile’s  position 


-  arctan2(a,b )  is  a  function  which  returns  the  arctan 


0  to  211,  based  on  the  sign  of  a  and  b. 


in  the  range 


Once  Dir(ft  is  known,  the  missile’s  new  X  and  Z  coordinates  can  be  calculated  as 


MXneu,  =  MXold  +  le03(Dirtgt)*ADist\  (6-6) 

MZn'W  =  MZold-lsin(D{rtgt)*AD{st\  (6‘7) 

Next  the  missile’s  altitude  (MY)  is  adjusted  a  proportion  of  the  total  altitude 
difference  between  it  and  the  target,  based  on  the  ratio  of  ADist  to  the  total 
distance  (along  the  horizontal  plane)  to  the  target. 


Distlai  W(  TX  -  MX)1, + ( TZ-MZ) z 

ADist 


MY  =MY 

new  old 


-TY) 


Dist 


tgt  J 
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Where 


-  Dist^t  is  the  distance  to  the  target  measured  along  a  horizontal  plane. 

-  MY  and  TY  are  the  Y  (altitude)  coordinates  of  the  missile  and  target, 
respectively. 


C.  DETERMINING  THE  LINE  OF  SIGHT 


Once  the  new  position  of  the  missile  has  been  calculated,  the  next  step  in 
displaying  the  terrain  is  to  determine  another  point  along  the  camera’s  line  of 
sight:  the  look-at  position.  This  calculation  is  also  broken  into  two  cases  based- 
on  whether  the  missile  is  or  is  not  locked  onto  a  target  (see  Figure  6.2). 

The  case  where  the  missile  is  locked  on  is  trivial,  the  look-at  position  is 
simply  set  to  the  coordinates  of  the  locked-on  target. 


LX  -  TX 

(6.10) 

LY=TY 

(6.11) 

LZ=TZ 

(6.12) 

Where  LX,  LY ,  and  LZ  are  the  X ,  Y,  and  Z  coordinates  of  the  look-at  position. 
This  centers  the  target  in  the  displayed  three-dimensional  scene. 

When  the  missile  is  not  locked  onto  a  target,  the  camera’s  look-at  position  is 
a  function  of  the  missile’s  position,  the  missile’s  heading,  and  the  pan  and  tilt 
angles  of  the  camera.  It  is  determined  as  follows 


d'tm  =  Hcadm,:+Pan 

(6.13) 

LX  =  MX+lcos(Dirl0J'Dist,"t\ 

(6.14) 

LZ  ~  MZ—Uitn  ( Dir  Dint,  . 

(6.15) 

LY  =  MY+[Distlook*t&n{Tilt)\ 

(6.16) 

Case  1  -  Missile  Locked  on  a  Target 


/ 


Overhead  View  | _ Side  View 

Case  2  -  Missile  Not  Locked  on  Target 


Figure  6.2  Determining  the  Camera’s  Look-at  Position 


Where 


-  Dir[ook  is  the  direction  the  camera  is  looking 

-  Pan  is  the  pan  angle  of  the  camera 

-  Tilt  is  the  tilt  angle  of  the  camera 

-  Dist[ggk  is  am  arbitrary  distance  over  the  ground  that  the  camera  looks  ahead. 
Since  the  only  purpose  of  LX,  L  Y,  and  LZ  is  to  determine  a  point  along  the 
camera’s  line  of  sight,  any  positive  number  will  be  acceptable.  A  value  of  five 
kilometers  is  currently  used. 

D.  DISPLAYING  THE  SCENE 

Once  a  line  of  sight  has  been  determined,  the  next  steps  are  to  apply  the 
appropriate  viewing  transformations,  draw  the  filled  polygons  that  make  up  the 
terrain,  and  add  other  items  to  the  scene  such  as  targets  and  roads. 

1.  Viewing  Transformations 

It  is  possible  to  project  a  three-dimensional  object  onto  a  two 
dimensional  viewing  surface  in  two  basic  ways.  In  one  method,  the  parallel 
projection  all  the  points  of  the  object  are  projected  along  parallel  lines.  This  has 
the  advantage  of  preserving  the  relative  dimensions  and  angles  within  an  object 
and  is  used  when  accurate  views  of  various  sides  of  an  object  are  needed  such  as 
in  architectural  drawings.  In  the  other  method,  the  perspective  projection,  all 
'he  points  of  an  object  are  projected  along  lines  that  converge  at  a  single  ooinr 
called  the  Center  of  Projection.  In  this  method,  relative  dimensions  are  not 
preserved.  Lines  closer  to  the  projection  plane  appear  larger  than  those  that  are 
more  distant.  The  perspective  projection  provides  a  view  of  three-dimensional 


objects  that  is  more  realistic,  similar  to  that  provided  by  the  human  eye  or  a 


camera.  Both  these  projections  are  illustrated  in  Figure  6.3.  [Ref.  ll:pp.  235-241] 
Because  of  its  more  realistic  presentation  of  the  scene,  a  perspective 
projection  was  used  for  the  project's  three-dimensional  scenes.  The  IRIS's 
graphics  library  provides  a  procedure  called  perspective  which  constructs  the 
necessary  transformation  matrix  *  to  obtain  a  perspective  projection.  The  matrix 
is  defined  as  [Ref.  7:p.  C-2] 


Perspective  ( fovy .aspect  .near  .far)  - 
.  fovy 

COt( - ) 

I  2 


aspect 


,  fovy , 

COt{ - ) 


0 


0 

0 

far  +  near 
far-near 
2x  far x  near 
far- near 


-1 


(6.17) 


Where 


-  fovy  is  the  field  of  view  angle 

-  aspect  .s  'he  aspect  ratio,  a  ratio  of  'he  distance  i  -.newer  sees  in  'he  X 
direction  *o  the  iistance  he  sees  in  'he  V  direction,  [t  is  generally  set  *o  be 

the  same  as  the  ratio  of  the  width  to  the  height  of  the  viewport. 

-  near  and  far  are  the  distances  from  the  viewer  to  the  near  and  far  clipping 
planes. 

*A  knowledge  of  using  transformation  matrices  to  perform  graphical  operations  is  assumed 
here.  Hearn  and  Baker  [Ref.  ll:chaps.  11-12  provides  excellent  coverage  of  the  subject. 


The  perspective  projection  forms  a  view  frustum  as  shown  in  Figure  6.4. 


Any  object,  within  the  frustum  between  the  near  and  far  clipping  planes  will  be 
displayed  in  the  scene.  Objects  outside  this  view  volume  are  clipped  and 
discarded. 

Next,  the  frustum  fomed  by  the  perspective  projection  must  be 
positioned  along  the  camera’s  line  of  sight.  This  is  accomplished  by  another 
transformation  matrix  constructed  via  a  graphics  library  procedure  named  lookat. 
The  lookat  procedure  takes  the  following  inputs: 

-  Vz,  V  ,  and  V 'g:  the  X,  Y,  and  Z  coordinates  of  the  center  of  projection. 

-  Pz,  P  ,  and  Pz:  the  X,  Y,  and -Z  coordinates  of  the  look-at  position. 

-  Twist ,  a  right  handed  rotation  of  the  scene  about  the  line  of  sight. 

The  transformation  matrix  formed  by  lookat  is  actually  the  result  of  multiplying 
four  other  transformation  matrices  [Ref.  7:p.  C-2] 

Lookat(Vz,Vy,Vz,Pz,Py,Pz, Twist)  = 

Trans{~  Vg,—  V  Vf)  x  Roty(S)x  Rotg(Q)x  Rotg(- Twist) 


10  0  0 


Where  Trans (  -  V  .-  V  -  V'  ) 


0  10  0 


(6.19) 


The  perspective  command  defines  a  near  and 

far  clipping  plane,  a  fie  la  of  view,  and 

an  aspect  ratio. 


Figure  6.4  The  Perspective  Command 


coa(0)  0 

-sm(0) 

0 

0  1 

0 

0 

«m(0)  0 

cos(0) 

0 

0  0 

0 

i 

1  0 

0 

0 

0  eos($) 

atn($) 

0 

0  - «in($ ) 

eoa($) 

0 

0  0 

0 

1 

eos(— Twist)  sin( 

-Twist)  0  0 

—  sin(—  Twist)  cos  ( 

-  Twist )  0  0 

I.l  *_l 


6.20 


Rot2(-Twist)  = 
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l  nd  0  =  sin 
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As  can  be  seen,  this  transformation  simply  translates  the  center  of  projection  to 
the  origin,  then  rotates  the  view  frustum  about  A'  and  Y  axes  to  align  with  the 
line  of  sight.  Finally  the  twist  angle  is  added  with  a  rotation  about  the  Z  axis. 
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In  the  flight  simulation,  the  twist  angle  is  analogous  to  the  “roll”  angle  of  an 
aircraft  or  missile.  A  value  of  zero  is  currently  used,  but  other  values  could  be 
used  if  the  roll  of  the  missile  during  flight  was  added  to  the  model. 

2.  Determining  Which  Polygons  to  Draw 

After  the  correct  viewing  transformations  have  been  applied,  the 
polygons  that  comprise  the  scene  must  be  drawn.  Although  the  IRIS  will  “clip” 
polygons  which  lie  outside  the  perspective  projection’s  view  volume,  an  increase  in 
frame  update  speed  can  be  achieved  by  not  attempting  to  draw  those  that 
obviously  lie  outside.  This  is  discussed  further  in  the  following  section  on 
simulator  performance. 

The  term  view  — bound  is  used  to  describe  a  north-south  oriented 
bounding  box  around  those  parts  of  the  scene  that  are  sent  to  the  graphics 
pipeline.  The  view-bound  is  described  by  the  index  of  the  northernmost, 
southernmost,  easternmost,  and  westernmost  gridsquare  to  be  drawn.  It  is 
calculated  by  extending  (if  necessary)  the  line-of-sight  vector  until  it  intersects  the 
horizontal  plane  Y  =  Min_elcv ,  where  Min  elev  is  the  minimum  elevation  value 
of  the  terrain.  The  view -bound  is  calculated  as  being  20  gridsquares  to  the 
north,  south,  east.,  and  west  of  this  intersection  point.  If  the  missile's  X  and  Z 
coordinates  are  not  witnin  the  calculated  w  -  hound,  the  bounds  are  extended  to 
include  them.  Figure  6.5  illustrates  this  construction. 
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Missile  Position  (MX,  MY,  MZ) 


1)  Line  of  sight  vector  is  extended  down 
to  intersect  the  minimum  elevation  plane. 

2}  View  bound  extends  20  gridsauares  north, 
south,  eat t  and  west  of  the  intersection 

3)  Bound  is  extended,  if  necessary  to 
include  the  missile’s  position. 


Figure  6.5  Construction  of  the  View-bound 


3.  Hidden  Surface  Removal 


A  final  detail  that  must  be  taken  care  of  is  the  removal  of  hidden 
surfaces  from  the  scene.  A  hidden  surface  is  simply  a  part  of  the  scene  that  is 
obscured  by  some  object  in  the  foreground,  such  as  a  valley  that  it  hidden  behind 
a  large  hill. 

The  IRIS  supports  a  method  in  hardware  called  Z- Buffering.  In  this 
method,  a  buffer  is  maintained  for  each  pixel  position  on  the  monitor  and 
contains  the  “depth”  (transformed  Z  coordinate)  of  the  part  of  the  scene  that 
generated  that  pixel.  Before  drawing  is  started,  the  buffer  is  initialized  to  the 
maximum  depth  value  (the  value  of  the  far  clipping  plane)  for  each  pixel  position. 
Before  each  new  pixel  is  drawn,  its  depth  is  compared  to  the  depth  stored  in  the 
buffer.  If  its  depth  is  greater  than  the  stored  depth  it  is  not  drawn.  If  it  is  less 
than  the  stored  depth,  it  is  drawn  and  its  depth  value  replaces  the  value  in  the 
buffer.  This  method  could  not  be  used  in  the  project  for  two  reasons.  First,  with 
comparisons  having  to  be  made  on  a  pixel-by-pixel  basis,  it  slows  down  the  frame 
update  rate  to  an  unacceptable  level.  Second,  the  IRIS  does  not  allow  the  use  of 
Z-buffering  and  double-buffering  at  the  same  time.  Double-buffering  is  necessary 
to  implement  the  animation  of  the  scenes. 

Another  •otnmon  method  of  induen  -urt'ac-*  removal  .s  'he  :>nintrr  - 
algorithm.  It  derives  its  name  from  the  way  a  painter  would  draw  a  scene  on 
canvas,  drawing  in  all  the  background  and  then  adding  foreground  objects  by 
painting  over  the  background  objects  they  obscure.  Implementing  this  algorithm 


in  computer  graphics  means  drawing  the  scene  in  an  ordered  fashion,  such  that 
the  most  distant  objects  from  the  viewer  are  drawn  first  and  those  closest  to  the 
viewer  are  drawn  last.  Since  the  gridsquares  comprising  the  terrain  form  well 
defined  rows  and  columns,  an  efficient  implementation  of  this  algorithm  is 
possible.  That  implementation  is  described  below. 

The  implementation  can  be  thought  of  on  a  conceptual  level  as  follows. 
A  line,  perpendicular  to  the  line-of-sight,  is  constructed  to  serve  as  a  pseudo¬ 
scanline.  Gridsquares  within  the  view-bound  are  drawn  as  they  are  intersected  by 
this  scanline.  The  scanline  is  first  positioned  along  the  line-of-si  ^ht  vector  so  that 
it  intersects  the  far  corner  gridsquare  of  the  view-bound.  After  all  the  gridsquares 
along  the  scanline  have  been  drawn,  it  is  moved  one  gridsquare  closer  to  the  view 
position,  along  the  line-of-sight  vector,  and  the  process  is  repeated.  This 
continues  until  all  the  gridsquares  within  the  view-bound  have  been  drawn. 
Figure  6.6  illustrates  this  process. 

From  Figure  6.6,  notice  that  each  scanline  passes  through  three 
gridsquares  in  a  column,  shifts  over  a  column,  then  passes  through  three 
gridsquares  in  the  next  column.  The  number  of  gridsquares  drawn  in  a  column 
for  rowl  before  advancing  to  the  next  column  for  row")  can  be  determined  by 
•omputing  Tie  'angem  >t  he  •u-aiiiineb  direction,  if  'he  magnitude  of  'he 
tangent  is  greater  than  1.0.  scanlines  will  run  and  shift  along  columns  of 
gridsquares  If  it  is  less  than  1  0,  scanlines  will  run  and  shift  along  rows  of 
gridsquares.  The  term  threshold  is  used  in  the  remainder  of  the  algorithm  to 
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describe  the  number  of  gridsquares  drawn  before  a  shift  of  column  (or  row)  takes 
place.  It  is  computed  as 


threshold.  =  i 


nearest  integer^  tan  (Dir .  ) 


nearest  integer 


(tan  (Dir  )) 


-l 


if 


if 


tan(Dtr  )  j  Js  1.0 

^  scan '  ^ 


tan(Dtr  ) 


(6.25) 


<1.0 


The  pseudocode  for  implementing  the  algorithm  is  shown  in  Figure  6.7. 
The  case  shown  is  for  a  line-of-sight  direction  that  is  in  the  first  octant  (between 

n 

0  and  —  radians).  The  algorithm  for  the  other  seven  octants  is  similar,  the 
4 

difference  being  the  direction  the  scan  line  advances,  and  the  direction  it  shifts 
when  the  threshold  is  reached.  Table  6.1  summarizes  these  parameters  for  all 


eight  octants. 

TABLE  6.1  VARYING  PARAMETERS  FOR  THE  SCANLINE  ALGORITHM 
BASED  ON  THE  OCTANT  OF  THE  LOOK  DIRECTION 


Octant 

Look  Directions 

Scan  Line  Advances 

When  Threshold  is  Reached 

From 

To 

From 

To 

1 

0 

n/4 

North 

South 

Shift  one  column  East 

2 

n/4 

n/2 

East 

West 

Shift  one  row  North 

3 

n/2 

3n/2 

West 

East 

Shift  one  row  North 

4 

3n/2 

n 

North 

South 

Shift  one  column  West 

5 

n 

5n/4 

South 

North 

Shift  one  column  West 

6 

>n  4 

on.  2 

West 

East 

;  Shift  one  row  South 

l 

on  2 

:n  4 

East 

West 

Shift,  one  row  South 

8 

7n/4 

2n 

South 

North 

Shift  one  column  East 

Notice  the  step  draw  gridsquare[z_index][x  index]  in  the  algorithm. 
Since  a  gridsquare  contains  terrain,  and  can  also  contain  roads  and  targets,  an 
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Calculate  the  threshold  value 

count  *-  0 

startxindex  <—  west_view_bound 
start  *  index  «-  north  view  bound 

While  start _*_index  >  south  view_bound  do 
i  index  —  start  z  index 
x  index  <-  start  x  index 

while  (x_index  ^  east_view  bound)  and  (z  index  ^  south  view  bound)  do 

{  traverse  a  scanline  } 

draw  gridsquarejz  index) lx  index] 

z  index  —  z  index  -  1  {move  it  one  gridsquare  south) 
count  «-  count  +  1 

if  count  =  threshold  then 

x  index  —  x  index  -1-  1  {move  it  one  gridsquare  east) 
count  «-  0  {  reset  count) 

endif 

end  while 

{move  on  to  next  scanline:  start  it  one  gridsquare  to  the  west} 
atart  x  «-  start  x  -  1 
count  *-  0 

if  (start  x  <  west  view  bound)  then 
start  x  <-  west  view_bound 
start  s  starts  -  threshold 
endif 

endwhile 


Figure  6.7  Pseudocode  for  the  First  Octant  Scanline  Algorithm 


ordering  of  these  parts  of  the  gridsquare  must  also  take  place.  The  two  triangles 
forming  the  terrain  are  drawn  first,  next  any  roads  are  drawn,  and  finally  any 
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targets  are  drawn.  The  details  of  integrating  the  targets  and  roads  into  the  scene 
are  covered  in  the  following  two  chapters. 

The  resulting  scene  is  shown  in  Figure  6.8.  a  photograph  of  the  IRIS 
monitor  during  the  flight  simulation.  Note  how  the  hidden  surface  removal  allows 
the  foreground  hills  to  naturally  obscure  the  valleys  behind  them.  Also  note  the 
effect  of  the  lighting  model  and  texturing  described  in  Chapter  V. 

E.  SIMULATOR  PERFORMANCE 

Data  collected  while  running  the  simulator  shows  that  the  average  frame 
update  rate  is  approximately  four  frames  per  second.  The  Unix  profile  utility 
was  used  to  determine  which  procedures  accounted  for  the  majority  of  the 
simulator’s  time  usage.  Table  6.2  shows  the  results  for  the  top  four  routines. 
TABLE  6.2  FOG-M  ROUTINES  USING  THE  MOST  CPU  TIME 


%  CPU  Time 

Routine  Name 

Purpose 

16.9 

polf 

Iris  graphics  library  filled  polygon  routine. 

13.7 

display  terrain 

Output  3-D  scene  with  hidden  surface  removal. 

8.7 

malloc 

C  language  built  in  routine  for  dynamic 
memory  allocation. 

4.5 

gl  findhash 

Low  level  Iris  graphics  library  routine,  used  for 

the  hash  tables  associated  with  graphical 
objects  (Not  user  accessible). 


The  *op  two  entries  in  iaoie  6.2  are  directly  Invoivea  with  outputting  polygons  to 

build  the  terrain  image.  It  is  therefore  reasonable  to  believe  that  the  frame 
update  rate  depends  heavily  on  the  number  of  polygons  that  are  passed  to  the 
geometry  engines. 
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Figure  6.9  is  a  scatterplot  showing  the  frame  update  speed  achieved  when 
various  numbers  of  polygons  were  attempted  to  be  drawn.  The  data  was 
generated  by  reading  the  system  clock  before  each  frame  update  and  calculating 
the  number  of  polygons  based  on  the  view -bound  that  was  used  during  that 
frame.  The  graph  clearly  shows  the  effect  the  view-bound  has  on  the  frame 
update  rate.  The  next  two  entries,  malloc  and  gl  findhash ,  are  traceable  to  the 
making  and  deleting  of  the  graphical  objects  that  store  the  targets  (this  process  is 
explained  in  Chapter  VII).  As  an  experiment,  the  construction  and  deletion  of 
the  targets’  objects  was  removed  from  the  simulation  and  the  targets  were  simply 
displayed  in  stationary  positions.  The  profile  results  from  the  simulator  run  in 
this  configuration  is  shown  in  Table  6.3.  Figure  6.10  is  another  scatterplot, 
generated  in  the  same  manner  as  Figure  6.9,  except  that  the  simulator  was  run  in 
the  stationary  target  configuration.  Eliminating  the  dynamic  memory 
management  associated  with  the  target’s  graphical  objects  increased  the  average 
frame  update  rate  from  2.99  to  3.90  frames  per  second.  Also,  the  maximum  frame 
update  rate  achieved  doubled  from  7.5  to  15.0  frames  per  second.  This  would 
suggest  that  an  area  for  further  research  is  an  improved  algorithm  for  target 
updating  ’’hat  does  not  involve  dynamically  allocating  memory. 

7’;-'  •;;.!!  •;.*■  frame  innate  -ate  .>  -<>  leaviiy  ieoenderit  on  'he  number  of 

polygons  passed  to  the  geometry  engine  suggests  that  a  more  sophisticated 
method  of  determining  the  view-bound  may  pay  off  in  increased  performance. 
For  example,  the  present  method  does  not  take  into  account  the  field  of  view 
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angle  It  should  be  possible  to  bound  the  line-of-sight  intersection  point  with  less 
than  twenty  grid  squares  when  the  field  of  view  angle  is  small  However  any  new 
algorithm  developed  ran  no*  be  so  sophisticated  that  it  negates  the  performance 
mcreaae  by  requiring  intensive  roniputat ions 
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VII.  TARGET  INTEGRATION 


A.  GENERAL 

The  primary  targets  of  a  FOG-M  missile  are  tanks,  helicopters,  and 
reinforced  ground  installations.  The  simulator  is  designed  to  handle  many  types 
of  targets,  including  various  tanks  and  helicopters,  but  only  a  single  type  of  tank 
is  currently  implemented.  The  prototype  Emulator  provides  an  Ethernet 
networking  capability  to  allow  the  input  of  actual  target  positions  in  real-time. 
This  simulates  the  input  that  would  be  -eceived  by  a  production  simulator  during 
computerized  mock  combat  field  experiments.  In  its  networking  mode,  the 
simulator  receives  target  position  and  orientation  data  from  an  interactive 
program  running  on  a  different  IRIS  workstation.  The  target  program,  still  in 
testing  and  not  detailed  in  this  study,  provides  the  capability  to  dynamically 
insert  and  delete  targets  at  any  location,  and  to  modify  their  speed  and  direction 
In  the  simulator  s  stand-alone  mode,  there  are  ten  tanks  defined  by  default  that 
criss-cross  the  ten  kilometer  square  terrain  area  These  tank  targets  move  at  a 
on--anf  >t  i  It  'mots  m<i  reverse  iirec’.on  vhej.  h  in*1  >i  • 

edges  ot  me  ten  Kilometer  terrain  square  .No  automated  patn  piamung  is 
presently  performed  in  either  mode,  so  the  tanks  blithely  traverse  even  the 


steepest  terrain.  The  default  targets  minimize  this  problem  by  traveling  the  length 
of  the  valleys  for  the  most  part. 

B.  TARGET  CREATION 

Target  creation  is  simplified  through  the  use  of  graphical  objects.  The  actual 
image  of  a  tank  is  defined  initially  by  the  tedious  specification  of  the  three 
coordinates  of  each  vertex  of  each  of  the  polygons  that  comprise  the  tank  (Figure 
7.1).  Using  objects,  this  need  only  be  done  once,  placed  in  an  object,  and  then 
referred  to  by  a  single  name  within  each  target  object  Thus  each  ♦arge*  Is 
described  by  an  object  (the  tank  object)  within  another  object  (the  target  object) 
In  addition  'o  the  rank  object,  the  target  object  also  contains  'he  'ransformanon 
commands  that  move  the  tank  from  the  origin  to  its  location  on  the  terrain  (a 
translation),  and  face  it  in  the  direction  it  is  moving  (a  rotation ). 

1.  The  System  Matrix 

The  rotation  and  translation  commands  work  by  modifying  the  system 
matrix.  The  system  matrix  is  a  global  data  structure  that  is  used  to  transform 
coordinates  from  the  three-dimensional  world  space  into  the  two-dimensional 
screen  space  Each  transformation  can  be  performed  as  a  senes  of  computations 
in  tmividuui  A"  !'  in«i  Z  •«M>r<iinates.  >ut  ;;«•  •  rniiMormat ion*  in  ,«• 

accomplished  with  a  single  matrix  multiplication  The  IRIS  has  a  matrix 
multiplier  built  into  its  hardware,  so  matrix  operations  are  very  efficient  At  least 
three  transformations  must  be  applied  to  every  endpoint  on  the  tank  a  coordinate 


scaling.  a  translation,  and  a  rotation  Rather  than  do  three  separate  matrix 
multiplications,  the  three  transformation  matrices  can  he  combined,  so  that  all  of 
the  transformations  are  accomplished  in  a  single  matrix  multiplication  The 
matrices  are  combined  by  applying  earn  of  mem  to  me  »ystern  matrix  hach 
point  is  now  completely  transformed  through  a  single  multiplication  with  the 
system  matrix  \N  hen  a  new  transformation  is  needed.  tne  system  matrix  must  tie 
reset  by  applying  the  inverses  of  the  old  transformations  or  by  copying  the 
original  contents  back  into  'he  system  matrix  Two  coinman  !»  an  provided  with 
tfie  IH  |  n  to  support  ttie  lat’er  metnoil  rtf  rane>  rt  i  op\  ot  tne  s\slelli 

matrix'*  current  contents  and  *ave»  r  on  the  nystmi  rfiirk  After  the 
? ransformat ions  uw  >e*  i  ,tpp.  .»;•<:  • »■  Iraw.ng  '.ia'  i»e<i  ■;in*ii 

transfort.  ttions  has  tieen  completed  *he  system  matrix  i*  reset  b\  calling 
poprnal  rtf  which  retrieves  the  <op>  placed  on  *  he  slack  b\  pushinatrix  and 
restores  the  contents  of  *  he  -olein  matrix  to  *  tie  prex  iousl\  -mn!  \  a  lues 
?  I  arget  Transformations 

I  tie  tank  i*  itn'iali'.  defined  w  th  o-  <  enter  interior  a'  ’tie  >ngm 

•  <  m  ird  i  n  a  t  es  ( (,t  M I  i  \A  hiie  '  no*  i  mport  a '  w  !.  n  ti  [miiiiI  on  or  in  *  fie  •  at;  k  - 

O 1  a  <  e*  f  |  '  #  tf  '  '  '  -  r  .1  a  !  ’  * ;  a  '  *  !  »  'a-  i*  ’  *  '  *  i  »  i  <  f  M  e  \S  1  »  r»  i  r  1  t 1  ;  '  '  ’  * 

direction  ot  the  tank  i*  Mgr,, *i'  ant  on{\  ’«>  '  t  •  cxt*>'  'tia'  o  no-'  ’>•  known  u 
order  to  i  aii  ula’e  t),,  appropriate  -■  •**’  e  u,  ?o  *«  t,  .*  •.  t  a  -pe«  tied  toad  rig  !  to 

*  ati  K  in  H  M  i  M  f  at  •  «  *<>  fin  ruth*  /t  r  •  radian-  m.a'  f.t  tua*  e  al.\  or  a  i  ■  u : .  i  m»- 


heading  of  ninety  degrees)  initially.  During  target  creation,  dummy  (zero  valued) 
rotation  and  translation  commands  are  placed  in  the  target  object,  to  be  updated 


for  display  by  a  'ater  editing  of  the  ob'ec*  ‘since  all  rotation  and  translation 
commands  affect  the  system  matrix  (as  previously  described)  and  are  cumulative, 
each  target  object  must  apply  its  transformations,  be  drawn,  and  then  remove 
those  transformations  so  that  latter  drawing  commands  are  not  distorted.  Within 
each  target  object,  the  contents  of  the  system  matrix  are  saved  with  a  pushmatrix 
call,  the  appropriate  rotation  and  translation  command1  are  applied  to  the  system 
matrix  (in  reverse  order,  due  to  the  nature  of  matrix  multiplication),  the  target  is 
iriw'i  ov  call-tig  *  he  '.mk  object,  arid  *  hen  popmatrix  is  called  to  reset  the  -Wem 
mat  r.x 

<  ANIMATION 

Animation  of  the  targets  is  accomplished  using  the  objects  and 
transformations  described  above  The  targets  must  be  moved  slightly  before 

being  redrawn  in  the  next  frame  This  requires  new  (  V.T.Z)  rcxtrdinates.  from  the 
network  or  from  Una  I  calculations  Then  a  global  data  structure  is  updated  to 
indicate  when  in  the  display  algorithm  the  target  should  he  drawn,  and  the 
i  *  i  1 1  ’  i  f .  ♦  i  . !  m  ♦  -  *  *  -  *;■*•••  i  r  •  • '  « 1 1  i « •  . »  '  \  *  t  >  r  .  : ; .  t '  *  ■  *■* 

As  each  train*  i'  displayed,  targets  appear  in  slightly  shifted  positions,  and  give 
the  appearance  of  animated  motion 
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The  calculation  of  new  coordinates  requires  the  maintenance  of  position, 
speed,  and  direction  data  for  each  target.  The  total  distance  traveled  between 
screen  updates  is  the  product  of  the  elapsed  'ime  (obtained  from  the  IRIS’s  real¬ 
time  clock)  and  the  target's  speed,  scaled  so  the  units  match.  In  the  networking 
version  of  the  simulator  this  is  done  remotely;  in  the  stand-alone  version 
everything  must  be  maintained  locally.  The  target’s  direction  of  travel  is  stored 
in  radians,  and  is  measured  using  the  standard  mathematical  convention  as 
opposed  to  a  compass  heading  (Figure  7.2)  This  allows  calculation  of  the  the 
appropriate  east/west  (A.Y)  and  north/south  (AZ)  movement  as  follows: 


A.Y 

cos{  dirr  ct  ion  1 

*  '.-rnc  '  <nr'<l  '  *cair 

'actor 

*  L 

AZ 

sin|  direction  1 

*  time  *  speed  *  scale 

factor 

(7  2 

The  new  target  {X.Z)  position  is  the  sum  of  the  old  position  and  the  offsets 
(A,Y.AZ)  from  Equations  7  1  and  7.2.  Since  all  of  the  current  targets  are  tanks, 
their  Y  coordinates  (altitude)  should  be  taken  from  the  height  of  the  terrain 
underneath  the  tank  This  is  obtained  from  the  DTED  interpolation  routine 
grid  level,  which  is  called  with  the  new  (.Y.Z)  coordinates  as  input  parameters 

D  OUTLAY 

’..••it -NT  vi-  .uni’ll  '  .’ic  ,'.;iii)i';i'  mu  >i  ’.'if  -tru*  ire  it  '.‘if  ;.i:,i  mu  ■  ;;«■ 

use  of  the  painter  s  algorithm  to  solve  the  polygon  ordering  problem  without 
resorting  to  slower  or  more  complicated  schemes  like  Z-butfering  or  Binary  Space 
Partitioning  [Ref  13).  Targets  cannot  merely  be  drawn  after  the  terrain  because 
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of  the  same  ordering  problem.  Otherwise,  targets  appear  in  front  of  everything, 
and  it  is  impossible  to  simulate  a  target  moving  out  of  sight  into  the  distance  or 
behind  some  terrain  feature.  The  implementation  of  the  target  display  algorithm 
is  greatly  facilitated  by  the  use  of  objects.  Objects  allow  the  grouping  of  drawing 
commands  into  a  subroutine-like  package,  which  can  be  edited  (effectively 
allowing  parameterization)  and  then  displayed  with  a  single  command.  A  two- 
dimensional  array  of  object  “names”  (the  object  -  name  array)  is  initialized  so 
each  element  of  the  array  represents  the  target  object  to  be  drawn  in  the  one 
hundred  meter  square  of  terrain  with  the  same  indices  Since  the  C  programming 
language  recognizes  the  value  integer  zero  as  FALSE,  and  anything  else  as  TRI  E, 
this  array  does  double  duty  as  an  array  of  booieans  indicating  the  presence  or 
absence  of  a  target  object  in  a  particular  one  hundred  meter  grid  square  (No 
target  objects  are  given  the  "name”  zero,  which  would  indicate  FALSE  )  A  list  of 
targets  is  used  to  reset  this  array  to  all  zeroes  before  each  screen  update  (i.e  only 
those  elements  that  contained  targets  need  to  be  zeroed)  so  maintenance  overhead 
of  the  array  is  minimized.  The  new  target  positions  are  received  over  the 
network,  or  are  calculated,  based  on  each  target  s  position,  speed,  and  direction. 


d  real-time  since 


innate 


he  ai»or< orate 
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array  is  updated  If  this  is  the  first  (or  only)  target  m  the  designated  one  hundred 
meter  grid  square,  the  update  is  accomplished  by  making  a  new  object,  and 


setting  the  object-name-array  element  equal  to  the  new  object’s  integer  name 


If  the  array  shows  that  some  other  target  is  already  in  that  particular  piece  of 
terrain  (i.e.  the  object-name-array  element  is  non-zero),  the  current  target  is  just 
added  to  the  object  specified  by  the  “name"  in  the  arrav  Once  this  has  been 
done  for  each  target,  this  array  is  available  for  the  display  terrain  module. 
Display  terrain  checks  the  array  as  it  draws  each  square  of  the  terrain  to  see  if 
any  targets  should  be  drawn.  If  so.  it  calls  the  indicated  target  object  just  after  it 
has  drawn  the  one  hundred  meter  grid  square  on  which  the  targetlsi  rests  Note 
that  this  causes  the  fargefis)  to  be  drawn  at  the  correct  t iw  for  the  painter  * 
algorithm  The  correct  place  to  draw  the  target  still  must  be  specified  b>  the 
* ransforma? ion  commands  within  'he  »arge*  . 

In  some  cases  it  ;s  necessary  to  draw  a  ’argt”  more  'Mai.  ot-.ce  larger*  ’.’.a’ 
straddle  a  one  hundred  meter  grid,  square  boundar>  must  be  draw.  or.  ’op  of  both 
or  possibly  ad,  four  grid  square*  in  order  ’o  avoid  t>eing  partia  i\  >bscured  S\ 
whichever  grid  square  i*  drawn  .'t  -The  target  m  i*t  be  drawn  mediates  At’1*' 
•  he  grid  square  on  which  ?  rest*  •«>  ensure  ’’.at  *  he  *arge*  «i,.  ’>♦  -u*.  urvu.  w 

it  should  be  by  ’errain  -ir<i«  r.  it,  »h»  f  >».  g-our.d  •  r,  <.  ..a*  .•*? 

boundary  nUTvct  ion  mv.ilvrs  *e\  era  "i.  *  .r.i  ’  .»n*  at  •  %■  i  s  r  • 

etiougl  to  rt  b.  «-j  ii  da  r\  ’  ha '  ’  .‘i*  mo**  '..*•<■  of  •*  ' '  •  '  o  •  ^  -  -s* 

boundary  *e.  ’ank*  t  at.d  /<  .:  I  g  .r*  '  ’•  •  •  •  ...  • 

rhe  adjoining  g'id  *q  jure  s 
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The  one  hundred  meter  grid  square  is  essentially  divided  into  three  areas: 
the  middle,  its  sides,  and  its  corners.  In  the  middle,  the  tank  cannot  overlap  any 
other  g-;d  square  On  the  sides,  the  tank  may  overlap  one  adjoining  grid  square, 
and  m  the  corners,  the  tank  may  overlap  three  adjoining  grid  squares.  The 
reference  point  on  the  tank  (the  position  the  X,Y,  and  Z  coordinates  refer  to)  is 
located  at  the  very  center  of  the  tank.  The  tank  is  thirty  feet  long,  so  the  most 
distant  parts  of  the  tank  are  within  a  fifteen  foot  radius  of  the  tank’s  reference 
point  The  lines  that  mark  the  side  and  corner  areas  are  thus  fifteen  feet  inside  the 
borders  of  the  grid  square.  Once  the  tank's  reference  point  is  within  these  areas, 
•  »  potentially  obscured  by  ‘he  later  drawing  of  the  adjacent  grid  square(s).  It 
might  not  be  obscured  if  it  is  paralleling  a  side,  for  example,  but  the  overhead  of 
ilrawmg  it  twice  (or  even  four  times)  when  it  does  not  need  to  be  is  smaller  than 
the  overhead  of  the  calculations  to  determine  if  the  position  and  direction  of  the 
tank  have  it  actually  crossing  one  or  more  edges. 

The  repeated  dravs  ing  is  accomplished  by  adding  a  “new”  target  to  the  array 
of  target  objects  The  •new”  target  object  is  drawn  at  the  exact  same  location  in 
th#  three-dimensional  terrain,  but  it  is  drawn  after  a  different  one  hundred  meter 
:*  :  -  :  .  -o  ■  w.il  have  different  ‘arget  object  array  indices,  and  be  in  a 
;  i  *  *  •  urge-  vet'.  -:;oug:i  die  two  vor  four;  targets  drawn  will  overwrite 

each  other  and  produce  a  single  image. 


VIII.  CULTURAL  FEATURE  INTEGRATION 


The  addition  of  cultural  features  add  much  to  the  realism  of  the  displayed 
scene.  They  also  provide  valuable  landmarks  from  which  a  person  observing  the 
scene  can  geographically  orient  himself.  This  chapter  covers  the  addition  of  one 
type  of  cultural  feature,  roads,  to  the  FOG-M  simulation.  Roads  were  chosen  as 
♦he  first  feature  to  add  because  of  the  special  problems  associated  with  their 
implementation,  the  ease  of  extracting  their  locations  from  contour  maps,  and  the 
visual  impact  added  to  all  parts  of  the  scene  due  to  their  wide-ranging  locations. 
Three  areas  will  be  discussed:  (1)  the  format  of  the  external  data  file  that  contains 
the  road’s  locations,  (2)  the  process  of  mapping  the  roads  onto  the  existing 
terrain,  and  (3)  the  integration  of  the  roads  into  the  terrain  display  loop. 

A  EXTERNAL  DATA  FILE  FORMAT 

The  data  being  used  in  the  simulation  was  obtained  by  manually  extracting 
the  roads'  positions  from  a  DMA  Topographic  Center  (DMATC)  contour  map  of 
’he  area.  Although  this  data  is  available  in  the  DMA’s  Digital  Feature  Analysis 

>■  i  DT  ViD  file.  -  fie*  -software  necessary  access  it  was  not  available.  The  road 
•  file's  format  is  such  that  the  DFAD  data  can  be  easily  used  when  the  access 
o  if 'ware  i'  developed 
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Figure  8.1  shows  a  segment  of  the  file  containing  data  for  two  roads  along 
with  a  diagram  showing  their  locations  within  the  terrain.  Each  road  entry  is 
composed  of  three  parts.  The  first  part  is  the  width  of  the  road  in  feet  Next  is 
an  integer  N ,  where  S  is  the  number  of  data  points  used  to  digitize  the  road. 
Third  is  a  set  N  coordinate  pairs,  where  each  pair  represents  the  location  of  a 
digitized  point  along  the  road’s  centerline.  The  first  coordinate  of  the  pair  is  the 
east- west  location  of  the  point.  It  is  measured  in  feet  from  the  western  terrain 
boundary.  The  second  coordinate  of  the  pair  is  the  north-south  location  of  the 
point,  measured  in  feet  from  the  southern  terrain  boundary.  All  the  data  is  stored 
as  ASCII  text,  which  facilitates  editing  of  the  data  using  any  text  editor.  The 
DFAD  data  file  also  contains  road  width  information  (in  meters)  and  stores  roads 
as  a  series  of  digitized  points.  The  major  difference  is  that  DFAD’s  points  are 
stored  as  latitudes  and  longitudes,  which  need  to  be  converted  before  they  can  be 
used  in  the  simulation.  [Ref.  9] 

B.  CONSTRUCTION  OF  THE  ROAD  POLYGONS 

Knowing  the  width  and  centerline  locations  for  the  road,  the  next  step  is  to 
construct  the  polygons  which  represent  it.  Although,  this  seems  like  a  simple 
procedure,  it  is  complicated  by  the  fact  that  Tne  road  must  follow  the  rise  and  fail 
of  the  terrain.  Also,  in  order  for  hidden  surface  elimination  to  occur,  the  road 
must  be  divided  at  the  gridsquare  boundaries  so  that  each  piece  can  be  drawn 
along  with  its  corresponding  gridsquare.  The  result  is  that  the  road  must  be 
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Figure  8.1  External  Data  File  Format 


broken  into  many  planar  polygons,  where  each  polygon  is  a  portion  of  the  road 
that  overlays  one  of  the  terrain  triangles  within  a  gridsquare.  Figure  8.2 
illustrates  this  division  and  defines  some  of  the  terms  used  in  the  description  that 
follows.  The  high  level  pseudocode  for  processing  the  road  data  and  constructing 
the  planar  polygons  is  shown  in  Figure  8.3.  As  the  pseudocode  shows,  each  road 
is  processed  a  segment  at  a  time.  For  each  segment 

-  The  end  points  of  the  segment’s  left  and  right  side  are  calculated.  A  look¬ 
ahead  to  the  next  road  segment  is  done,  allowing  the  ends  of  adjacent 
segments  to  be  calculated  so  that  they  meet  cleanly. 

-  A  bounding  box,  which  contains  all  the  griasquares  intersected  by  the 
segment,  is  constructed. 

Next,  for  each  gridsquare  in  the  bounding  box,  the  road  segment  is  divided  into 
the  road-polygons  at  the  gridtriangle  boundaries.  Note  that  all  the  vertices  of  the 
road-polygons  fall  into  one  of  five  types: 

-  The  intersection  of  a  segment’s  left  side  with  the  side  of  a  gridtriangle. 

-  The  intersection  of  a  segment’s  right  side  with  the  side  of  a  gridtriangle. 

-  A  gridsquare’s  cornerpoint  that  is  contained  within  the  road  segment. 

-  An  endpoint  of  the  left  side  of  the  road. 

-  An  endpoint  of  the  right  side  of  the  road. 

The  road  polygon  is  constructed  by  finding  all  the  above  vertices  which  exist,  and 
ordering  them  counterclockwise.  The  counterclockwise  ordering  is  necessary  for 
backface  polygon  removal  to  take  place.  The  intersections  oniy  detine  the  X  and 
Z  coordinates  or  the  vertices.  The  Y  (elevation)  coordinate  is  found  by 
interpolating  between  the  terrain’s  elevation  at  the  three  corners  of  the 
corresponding  gridtriangle. 
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While  more  data  in  the  road  data  file  do 
read  width  of  road 
read  number _of_point» 

read  *<»gment>  itart  <-oordinate  pair  I seg  start) 
read  tegmeni  s  end  coordinate  pair  ;seg_-nd) 

for  i  =  S  to  number  of  point*  +  1  do 

if  i  ^  number_of  points  then 

read  the  next  segment's  end  coordinate  pair  (next_seg  end) 

else 

next _seg  end  _x  *-  seg_end_x 
next  seg_end_*  ♦-  seg  end  i 
endif 

calculate  the  start  and  end  points  for  the  segment’s  left  and  right  side 

(left  start,  left  end,  right  start.  right_end) 

calculate  a  bounding  box  around  the  road  segment 


for  each  gridsquare  within  the  bounding  box  do 

Construct  the  polygon  which  overlays  the  gridsquare’s  northern  triangle 
Add  the  polygon  to  the  road  object  associated  with  this  gridsquare 

Construct  the  polygon  which  overlays  the  gridsquare’s  southern  triangle 
Add  the  polygon  to  the  road  object  associated  with  this  gridsquare 
right  start  «-  right  end 

endwhile 

Figure  8.3  Pseudocode  for  Constructing  Road  Polygons 


C.  INTERNAL  ROAD-POLYGON  STORAGE 

A  global,  two-dimensional  array  of  graphicalobjects ,  named  road ,  is  used  to 
store  the  road  polygons.  Each  entry  in  the  array  corresponds  to  the  pieces  of  road 
that  lie  within  a  gridsquare.  An  object  is  created  when  the  first  road-polygon  is 
constructed  for  a  gridsquare,  with  subsequent  road-polygons  being  inserted  into 


the  already  existing  object.  Since  the  roads  are  static  in  nature,  the  use  of  objects 


does  not  present  the  dynamic  memory  allocation  problems  associated  with  their 
use  in  storing  targets  (see  the  Simulator  Performance  Section  of  Chapter  VI).  As 
each  gridsquare  of  the  terrain  is  drawn,  a  check  is  made  to  see  if  a  road  object 
exists  for  that  square.  If  one  does  exist,  the  associated  road-polygons  are  drawn 
immediately  after  the  terrain.  This  insures  that  hidden  surface  elimination  occurs 
for  the  roads  as  well  as  the  terrain.  A  photograph  of  terrain  which  includes  some 
sections  of  roads  can  be  seen  in  Chapter  VII,  Figure  7.1). 
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IX.  FOG-M  SIMULATOR  USER’S  GUIDE 


A.  OVERVIEW 

This  section  of  the  report  is  a  user’s  guide  to  running  the  FOG-M  simulator. 
The  simulator  was  built  to  be  largely  self  documenting.  Instructions  are  clearly 
displayed  on  the  screen,  including  diagrams  which  serve  as  a  reminder  of  the 
functions  of  the  various  controls.  A  knowledge  of  the  logon  procedure  for  the 
IRIS  workstation  and  the  basic  commands  of  the  UNIX  operating  system  is 
assumed. 

B.  STARTING  THE  SIMULATION 

To  start  the  simulation,  logon  to  the  IRIS  workstation  and  use  the  UNIX  cd 
command  to  change  to  the  directory  containing  the  simulation.  Currently  the 
simulation  is  in  the  directory  /work/terrain.  Therefore  issue  the  command: 

cd  /work/terrain 

Next,  start  execution  of  the  simulation  by  typing  the  command  fogm.  A 
welcome  screen  will  appear  on  the  display  as  shown  in  Figure  9.1.  Pressing  all 
three  of  the  mouse  buttons  simultaneously  will  stop  the  program  and  return 
to  the  UNIX  command  level.  This  option  of  pressing  all  three  buttons  to  exit  is 
available  at  any  time  during  the  execution  of  the  program.  Pressing  the  middle 


mouse  button  advances  the  display  to  the  next  screen  of  instructions.  When  the 


user  has  advanced  through  the  welcome  screen  and  the  two  instruction  screens 
(Figures  9.2  and  9.3)  he  is  presented  with  a  display  showing  a  two-dimensional 
contour  map.  This  is  the  prelaunch  phase  of  the  simulation. 

C.  PRELAUNCH  CONTROLS 

The  purpose  of  the  prelaunch  phase  is  to  allow  the  user  to  designate  a  missile 
launch  position  and  a  suspected  target  location  position.  In  effect,  the  user 
describes  an  initial  flight  path  for  the  missile. 

1.  The  Prelaunch  Display 

The  prelaunch  display  is  divided  into  three  sections  as  shown  in  Figure 
9.4.  The  upper  right  corner  of  the  display  contains  an  instruction  box  which 
summaries  the  functions  of  the  mouse  buttons  for  this  phase.  The  lower  right 
corner  contains  a  prelaunch  statistics  box.  The  meanings  of  the  various  items 
within  the  statistics  box  are  explained  below.  The  majority  of  the  display  is 
occupied  by  a  two-dimensional  contour  map.  Each  of  the  square  grids  on  the 
contour  map  represents  a  one  square  kilometer  area.  The  colors  on  the  map  can 
be  interpreted  as  follows.  Green  areas  indicate  terrain  that  is  covered  with 
vegetation  that  is  greater  than  one  meter  high.  Brown  areas  indicate  terrain 
where  the  vegetation  is  less  than  one  meter  high.  Within  each  oi  the  coior 
categories,  the  elevation  of  the  terrain  is  indicated  by  the  intensity  of  the  color, 
with  the  brighter  colors  representing  the  higher  elevations. 


PRE-LAUNCH  ORIENTATION 


I 


2.  Selecting  the  Launch  Position 

The  launch  position  must  be  selected  first.  To  select  the  launch  position, 
use  the  mouse  to  move  the  red  arrow  cursor  to  the  desired  location  on  the  contour 
map.  As  the  cursor  is  moved,  the  UTM  coordinates  of  the  current  cursor  location 
are  shown  in  the  Launch  Position  field  of  the  statistics  box.  These  coordinates 
can  be  used  when  a  more  accurate  selection  of  the  launch  position  is  required  than 
is  obtainable  from  the  contour  map  alone.  When  the  cursor  is  in  the  desired 
position,  press  the  left  mouse  button  to  lock  in  that  position.  A  blue  circle  will 
appear  on  the  contour  map  showing  the  position  selected  and  the  workstation  will 
“beep,”  confirming  the  selection.  The  launch  position  can  be  changed  any  time 
before  the  launching  of  the  missile  by  simply  moving  to  the  new  desired  location 
and  pressing  the  left  mouse  button. 

3.  Selecting  the  Target  Position 

The  target  position  can  only  be  selected  after  a  launch  position  has  been 
set.  After  the  launch  position  has  been  selected,  moving  the  cursor  over  the 
contour  map  produces  the  following  effects: 

-  The  UTM  coordinates  of  the  current,  cursor  position  are  shown  in  the  Targ*  • 
Location  field  of  the  statistics  box. 

-  A  "rubber  band”  line  is  drawn  on  "lie  ••on tour  man  Von.  ;;*•  .• 

*o  the  current  cursor  location.  This  line  reare-mt*.  ie 

would  take  if  the  current  cursor  position  was  selected  as  the  Uirget  ,n 

-  The  direction  and  length  of  the  flight  path,  represented  t->  t\.  .r . 

displayed  in  the  statistics  box  in  the  Heading  ami  Pi-tarn  *  m  >  -•  - 

Once  the  cursor  is  at  the  desired  target  location  pr»->-  •*.  right  n  <  >  t 
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to  lock  in  the  position.  A  red  circle  will  appear  on  the  contour  map  showing  the 
selected  location  and  the  workstation  will  “beep,”  confirming  the  selection. 

The  missile  is  now  ready  for  launch.  The  target  location  can  be  changed 
any  time  before  launch  by  simply  moving  the  cursor  to  the  desired  new  location 
and  pressing  the  right  mouse  button. 

4.  Launching  the  Missile 

Launching  can  not  take  place  until  both  a  launch  and  target  location 
have  been  selected.  If  the  launch  and  target  locations  selected  are  acceptable,  the 
missile  is  “launched”  by  pressing  the  middle  mouse  button. 

If  this  is  the  initial  launch  of  this  execution  of  the  program,  a  several 
(three  to  four)  minute  delay  will  follow  during  which  calculations  are  done  to 
construct  the  upcoming  three-dimensional  scenes.  Again,  this  delay  only  occurs 
during  the  first  launch  of  any  execution.  Subsequent  launches  proceed  with  no 
delay.  During  this  delay,  a  countdown  will  appear  in  the  bottom  of  the  statistics 
box.  Launch  occurs  when  the  countdown  reaches  zero. 

D.  IN-FLIGHT  CONTROLS 
1.  The  In-Flight  Display 

After  the  missile  is  launched,  the  display  changes  to  the  in-flight  display 

shown  in  Figure  9.5.  The  left  side  of  the  display  contains: 

-  A  three-dimensional  view  of  the  terrain  as  seen  from  the  missile’s  camera. 

-  A  slider  bar  scale  along  the  bottom  edge  indicating  the  camera  pan  angle. 


-  A  slider  bar  scale  along  the  left  hand  edge  indicating  the  camera  tilt  angle. 

-  A  box  in  the  lower  left  corner  containing  either  the  word  DESIGNATE  or 
REJECT.  The  word  DESIGNATE  in  this  box  indicates  that  the  missile  is 
not  locked  on  to  a  target  and  is  waiting  for  a  command  to  designate  one. 
The  wor  1  REJECT  indicates  that  the  missile  is  locked  on  t,o  a  target  and  is 
waiting  for  a  command  to  reject  that  target. 

-  Cross  hairs  used  to  sight  the  camera  onto  a  target. 

The  upper  right  corner  of  the  display  contains  a  scaled  copy  of  the  contour  map 
seen  in  the  prelaunch  phase.  The  red  arrow  superimposed  on  the  contour  map 
shows  the  missile’s  current  position  (the  tail  of  the  arrow)  and  its  direction  of 
flight.  The  red  rectangle  on  the  map  indicates  that  area  of  the  terrain  that  is 
currently  being  shown  in  the  three-dimensional  display. 

The  middle  right  section  of  the  display  contains  four  indicators  which 
show  the  following: 

-  The  speed  of  the  missile  in  knots. 

-  The  direction  the  missile  is  traveling  in  degrees. 

-  The  height  of  the  missile  above  ground  level  (AGL)  in  feet. 

-  The  height  of  the  missile  above  mean  sea  level  (MSL)  in  feet. 

-  A  slider  bar  indicating  the  zoom  setting  of  the  camera  in  degrees. 

The  lower  right  section  of  the  display  contains  a  summary  of  the  functions 
performed  by  the  mouse  and  dials.  These  are  explained  further  below.  The  in¬ 
flight  phase  continues  until  the  missile  impacts  a  designated  target  or  all  three 
mouse  buttons  are  pressed  simultaneously  (to  stop  the  execution  of  the 
simulation). 


2.  Controlling  the  Camera 


The  ranges  and  initial  values  of  the  camera's  functions  are  shown  in 
Table  9.1.  All  of  the  camera’s  functions  are  controlled  with  the  mouse. 

-  To  pan  the  camera,  move  the  mouse  left  or  right  as  needed. 

-  To  tilt  the  camera,  move  the  mouse  up  or  down  as  needed. 

-  To  zoom  in  to  a  tighter  field  of  view,  press  the  left  mouse  button. 

-  To  zoom  out  to  a  wider  field  of  view,  press  the  right  mouse  button. 

3.  Controlling  the  Missile  Flight 

The  missile  can  be  controlled  by  changing  its  direction,  speed,  and 
altitude.  The  ranges  and  initial  values  of  each  of  the  flight  parameters  is  shown 
in  Table  9.2.  The  missile  flight  parameters  are  controlled  by  using  the  dials  on 
the  IRIS’s  button/dial  box  (see  Figure  9.6).  Dial  zero  (lower  left)  controls  the 
missile’s  direction,  dial  one  (lower  right)  controls  the  missile’s  altitude,  and  dial 
two  (above  dial  zero)  controls  the  missile’s  speed.  Refer  to  the  display’s  control 


TABLE  9.1  CAMERA  CONTROL  RANGES  AND  INITIAL  VALUES 


Control 

Range 

Initial  Value 

Maximum 

Minimum 

Pan 

Tilt 

Zoom 

25  degrees  right 

25  degrees  down 
55  degrees 

25  degrees  left 
15  degrees  up 

8  degrees 

0  degrees 

15  degrees  down 
55  degrees 

TABLE  9.2  MISSILE  CONTROL  RANGES  AND  INITIAL  VALUES 


Control 

Range 

- 

Initial  Value 

Maximum 

Minimum 

Altitude 

10,000  MSL 

200  AGL 

200  AGL 

Speed 

400  kts 

0  kts 

200  kts 

Direction 

359.9  degrees 

0  degrees 

From  prelaunch 

Figure  9.6  IRIS  Dial  Box  Fuctions 


summary  box  for  a  reminder  of  each  dial’s  purpose  and  location  during  flight. 
The  controls  are  used  as  follows: 

-  Direction  of  flight  -  Turning  dial  zero  clockwise  turns  the  missile  to  the 
right.  Turning  it  counterclockwise  turns  it  to  the  left.  The  missile  will  move 
freely  through  the  360  degree  mark  so  that,  for  example,  turning  the  missile 
right  two  degrees  from  a  heading  of  359  degrees  will  produce  a  heading  of 
001. 

-  Altitude  -  Turning  dial  one  clockwise  increases  the  missile’s  altitude  up  to 
the  maximum  of  10,000  feet  MSL.  Turning  the  dial  counterclockwise 
decreases  the  missile’s  altitude.  The  simulator  will  not  allow  an  altitude  to 
be  selected  that  is  less  than  200  feet  above  ground  level. 

-  Speed  -  Turning  dial  two  clockwise  increases  the  missile’s  speed,  while 
counterclockwise  decreases  the  speed. 

4.  Designating  and  Rejecting  Targets 

The  middle  mouse  button  is  used  to  designate  (lock  on  to)  and  reject 

(release  the  lock  on)  targets.  When  the  missile  is  not  locked  on  to  a  target  the 

word  DESIGNATE  will  appear  in  the  lower  left  corner  of  the  display.  To 

designate  a  target,  center  the  target  within  the  cross  hairs  and  press  the  middle 

mouse  button.  In  order  for  the  missile  to  lock  on,  some  portion  of  the  target 

must  be  in  the  center  of  the  cross  hairs.  If  the  designation  is  successful,  the 

workstation  will  “beep”  and  word  REJECT  will  appear  in  place  of  the  word 

DESIGNATE  on  the  display.  Once  a  target  is  designated  the  missile  will 

automatically  adjust  its  beading  and  altitude  "o  home  in  on  "he  selected  target. 

An  explosion  is  displayed  after  impact  with  the  target  occurs.  The  user  is  then 

returned  to  the  prelaunch  phase  of  the  simulation  to  begin  another  launch. 


A  locked  on  target  can  be  rejected  and  missile  flight  control  returned  to 


tl  j  user  by  pressing  the  middle  mouse  button  any  time  before  impact  with  the 


target  occurs.  The  workstation  will  respond  with  a  “beep”  and  the 


reject /designate  box  will  again  show  the  word  DESIGNATE.  The  missile  is  now 


ready  to  accept  the  designation  of  a  new  target. 


iif  iwwwy  ra* 


X.  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  LIMITATIONS 

There  are  several  limitations  to  the  flight  simulator  presented  in  this  study. 
First,  a  trade-off  had  to  be  made  between  resolution  and  frame  update  (display) 
speed.  Even  though  data  was  available  at  a  resolution  of  twelve  and  one-half 
meters,  the  simulator  uses  one  hundred  meter  resolution  in  order  to  achieve  an 
acceptable  frame  update  rate. 

Second,  the  simulator’s  flight  is  confined  to  a  ten  kilometer  square  area.  Any 
ten  kilometer  square  area  of  the  DTED  file  can  be  used  during  a  run  of  the 
simulation,  but  the  simulator  must  be  exited  before  switching  to  a  new  area.  This 
limitation  is  not  too  restrictive  for  the  current  range  of  the  FOG-M,  but  may  be 
inadequate  if  the  range  of  the  missile  is  increased  as  planned. 

Third,  road  data  is  available  in  a  format  usable  by  the  simulator  for  only  one 
10  kilometer  square  area.  Since  access  routines  were  not  developed  for  the  DFAD 
data  file,  roads  must  be  digitized  by  hand. 

Fourth,  the  simulator  does  not  model  any  of  the  missile's  flight,  dynamics.  As 
stateu  eariier,  this  limitation  was  imposed  only  because  of  development  time 
constraints.  It  is  felt  that  the  dynamics  can  be  acceptably  modeled  without 
adversely  affecting  the  performance. 


B.  FUTURE  RESEARCH  AREAS 


A  follow-on  to  this  project,  which  will  provide  more  realistic  targets  and 
allow  viewing  of  the  scene  as  seen  from  inside  any  of  them,  is  currently  underway 
at  the  Naval  Postgraduate  School.  The  project’s  plans  are  to  use  the  Ethernet  to 
allow  several  workstations  to  take  part  in  the  simulation  simultaneously.  Each 
workstation  will  control  one  weapon  (a  target  or  the  missile)  and  its  monitor  will 
display  the  scene  as  viewed  from  that  weapon. 

Work  is  also  underway  at  the  Naval  Postgraduate  School  in  the  use  of 
digitized  photographic  images  on  the  IRIS.  This  work  could  possibly  be 
incorporated  into  the  FOG-M  project  through  the  use  of  digitized  target  images, 
digitized  cultural  features,  or  digitized  textures  for  the  terrains. 

Another  possible  research  area  is  the  addition  of  various  environmental  effects 
into  the  simulation.  These  include  clouds,  smoke,  and  rain,  which  affect  the 
camera’s  view  by  reducing  visibility,  and  also  dust,  which  aids  the  missile 
operator  in  acquiring  moving  targets. 

Much  work  could  be  done  in  the  area  of  the  missile’s  flight  dynamics.  The 
goal  would  be  to  provide  an  acceptably  accurate  model  without  too  much  of  a 
sacrifice  in  speed. 

C.  SUMMARY  AND  CONCLUSIONS 

The  project  has  proven  the  practicality  and  feasibility  of  building  a  low-cost 
flight  simulator  with  commercial,  off-the-shelf  hardware.  With  a  relatively  small 


APPENDIX  A  -  MODULE  DESCRIPTIONS 


BUILD  ROAD. C 

Input:  None. 

Output:  None. 

Side  Effects:  Modifies  the  global  array  road ,  an  array  of  graphical  objects,  where 
each  object  contains  the  polygons  representing  the  road  in  a 
particular  gridsquare. 

Description:  Build_road  reads  the  file  road  width  and  centerline  information 

from  the  file  Road.data  and  constructs  polygons  which  represent 
the  road.  The  polygons  are  stored  in  the  array  of  graphical  objects 
road.  A  more  detailed  discussion  of  building  the  roads  is  contained 
in  Chapter  VIII. 

BUILDTERRAIN.C 

Input:  None. 

Output:  None. 

Side  Effects:  Buildttrrain  modifies  the  global  arrays  3avetriangle  and  gridcolor. 

Description:  Buildttrrain  reads  terrain  height  information  from  the  global  array 

gridpixel  and  constructs  the  terrain  as  a  set  of  planar  triangles. 
The  details  of  constructing  the  triangles  and  the  format  of  the 
savetriangle  and  gridcolor  arrays  can  be  found  in  Chapter  VI. 

COLORRAMP.C 

Input:  The  inputs  to  colorramp  are  two  booleans,  greyscale  and  init.  If 

greyscale  is  TRUE,  the  terrain,  sky,  and  target  colortable  entries 
are  defined  in  shades  of  grey  to  produce  a  black-and-white  image. 
If  greyscale  is  FALSE,  the  terrain  colors  are  green,  the  sky  is  blue, 
and  targets  are  brown.  Init  is  set  to  TRUE  when  this  routine  is 
initially  called,  so  that  every  entry  in  the  colortable  is  defined, 
including  those  tor  terrain,  sky,  targets,  and  writemasked  lines  on 
cop  of  the  contour  maps,  should  the  display  be  switched  between 
color  and  black-and-white,  only  the  terrain,  sky,  and  target  entries 
need  to  be  redefined,  which  is  what  happens  when  init  is  FALSE. 

Output:  None. 

Side  Effects:  Colorramp  changes  the  system’s  col  actable,  and  thus  determines 
the  colors  that  appear  on  the  display  for  the  images  drawn  by 
other  routines. 


Description:  Colorramp  is  called  by  the  main  program  fogm  as  part  of  the 

initialization  that  takes  place  before  the  flying  loop  is  entered.  At 
that  point,  greyscale  is  set  to  its  default  value  (usually  FALSE, 
indicating  color  images)  and  init  is  TRUE.  The  readcontrols 
routine  also  calls  colorramp  to  toggle  the  display  image  between 
color  and  black-and-white,  based  on  the  position  of  one  of  the 
dials.  This  call  is  made  with  the  desired  value  for  greyscale  and 
with  tntf  FALSE.  Colorramp  uses  the  IRIS  routine  mapcolor  to 
directly  update  the  colortable  for  the  contour  map  colors,  and  calls 
the  user  written  routine  gammaramp  to  define  appropriately 
shaded  ranges  of  the  greens  and  browns  (or  greys)  used  for  the 
terrain  and  targets. 

COMPASS. C 

Input:  Compass  rakes  as  input  a  float,  direction,  which  is  an  angle  in 

radians. 

Output:  Compass  returns  a  float  which  is  the  compass  direction  in  degrees 

corresponding  to  the  input  direction. 

Side  Effects:  None. 

Description:  The  function  Compass  converts  an  radian  angle  measured  using 

the  standard  mathematical  convention,  and  converts  it  to  a  degree 
angle  measured  using  the  standard  navigational  convention. 

DISP  TERRAIN. C 

Input:  Display  terrain  takes  eleven  inputs:  the  X,  Y,  and  Z ,  coordinates 

of  the  missile  position  VX,  VY,  and  VZ\  the  X,  Y,  and  Z 
coordinates  of  the  camera’s  look-at  position  PX,  PY,  PZ;  the  field 
of  view  angle  ( camera,  zoom  value),  FOVY;  and  the  X  and  Z 
ranges  of  gridsquares  to  be  displayed,  FIRST _X,  FIRST _Z, 
LAST _X  and  LAST  Z. 

Output:  None. 

-nde  E {fee's:  None. 

Description:  Dtsp  :  err  am  >urputs  a  frame  of  ‘he  terrain  scene  ro  the  monitor 

using  a  hidden  surface  algorithm.  The  scene  contains  terrain, 
roads,  and  targets.  Details  of  the  hidden  surface  algorithm  can  be 
found  in  Chapter  VI. 


DIST  TO  LOS.C 


Input:  Dittjojos  takes  seven  inputs:  the  X ,  Y,  and  Z  coordinates  of  the 

start  of  a  line  segment;  the  X,  Y ,  and  Z  coordinates  of  the  end 
point  of  a  line  segment;  and  three  dimensional  array,  pt,  which 
contains  the  coordinates  of  a  point. 

Output:  Dist  to  los  returns  a  float  which  is  the  perpendicular  distance 

from  the  input  point,  pt,  to  the  input  line. 

Side  Effects:  None. 

Description:  Function  which  computes  the  perpendicular  distance  from  a  point 

to  a  line  in  three-space. 


DO  BOUND  ARY. C 


Input: 


Do  boundary  takes  the  following  inputs: 

-  An  integer  Bound  type  which  is  interpreted  as: 

0  -  a  diagonal  boundary 

1  -  a  horizontal  boundary 

2  -  a  vertical  boundary 

-  An  integer  which  triangle  that  is  interpreted  as: 

0  -  the  lower  triangle  of  the  gridsquare. 

1  -  the  upper  triangle  of  the  gridsquare. 

-  The  indices,  x grid  and  zgrid,  of  the  gridsquare  for  which  the  road 
is  being  constructed. 

-  The  coordinates  of  the  start  point  of  the  boundary  stored  in  a 
three  dimensional  array,  bound  start. 

-  The  coordinates  of  the  end  point  of  the  boundary  stored  in  a 
three  dimensional  array,  bound  end. 

-  The  coordinates  of  the  start  point  of  the  left  side  of  the  road 
stored  in  a  three  dimensional  array,  left  start. 

-  The  coordinates  of  the  end  point  of  left  side  of  the  road  stored  in 
a  three  dimensional  array,  left  end. 

-  The  coordinates  of  the  start  point  of  the  right  side  of  the  road 
stored  in  a  three  dimensional  array,  right  start. 

-  The  coordinates  of  the  end  point  of  right  side  of  ''he  road  stored 
in  a  three  dimensional  array,  right  rnd. 

-  A  boolean,  start ^corner  flag,  which  is  TRUE  if  the  gridsquare 
corner  at  the  boundary’s  start  is  ALREADY  in  the  road  polygon 
array,  FALSE  otherwise. 

-  A  boolean,  end_corner  flag,  which  is  TRUE  if  the  gridsquare 
corner  at  the  boundary’s  end  is  ALREADY  in  the  road  polygon 
array,  F ALSE  otherwise. 

-  The  partially  complete  road  polygon  array,  road  poly. 


FlTl, 


-  An  integer,  vertex  ent.  that  is  the  number  of  vertices  currently  in 
the  roadjpoly  array. 

Output:  Do  boundary  outputs  the  following: 

-  start  corner  flag  (see  Inputs  for  a  description) 

-  end  corner  flag  (see  Inputs  for  a  description) 

-  road  poly,  the  road  polygon  array  with  the  vertices  along  this 
boundary  added. 

-  vertex  ent  (see  Inputs  for  a  description) 

Side  Effects:  None. 

Description:  Do  boundary's  purpose  is  to  find  all  the  intersections  of  the  road’s 

left  and  right  sides  with  the  input  boundary  of  a  gridtriangle.  As 
an  intersection  is  found  the  point  is  put  into  a  temporary  array. 
After  all  the  intersections  are  found  for  the  boundary  the  points  in 
the  temporary  array  are  sorted  then  added  to  the  existing 
road  poly  array.  The  order  of  the  sorting  is  such  that  the  resulting 
road  poly  array  will  be  ordered  counterclockwise.  See  Chapter 
VIII  for  a  detailed  description  of  building  the  roads. 

EDIT  INDBOX.C 

Input:  The  inputs  to  edit  indbox  are  the  name  of  the  indicator  object,  the 

tags  within  that  object  for  each  of  the  indicators,  and  current 
values  for  the  following  missile  parameters:  X,Y,  and  Z  position 
coordinates,  pan,  tilt,  and  zoom  angles,  and  designate/reject 
status. 

Output:  None. 

Side  Effects:  Since  edit  indbox  changes  the  indicator  object,  it  has  the  side 
effect  of  changing  the  display  when  the  indicator  object  is  next 
called  and  displayed. 

Description:  The  indicator  object  is  edited  between  each  display  frame  so  that 

the  heads-up  display  and  the  indicator  box  indicators  show  the 
current  values  for  the  missile’s  speed,  heading,  altitude,  camera 
pan  angle,  camera  tilt  angle,  camera  *ield  of  view  (zoom),  and 
designate/ reject  status.  The  input  speed,  .leading,  and  MSL 
altitude  i  Y  position  ••oordinatej  .ire  -onverted  :o  strings  for 
display.  AGL  altitude  is  calculated  as  the  difference  between  MSL 
altitude  and  the  elevation  of  the  ground  directly  below  the  missile 
as  obtained  from  gnd  level  with  the  X  and  Z  position  coordinates 
as  input.  The  boolean  designate  determines  whether 
“DESIGNATE”  or  “REJECT”  is  printed  in  the  lower  left  corner 
of  the  terrain  display.  Finally,  the  positions  of  the  tilt,  pan,  and 
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zoom  indicators  are  calculated  from  the  missile  parameters.  The 
equations  in  the  code  have  been  simplified  to  avoid  excess 
computation;  the  derivations  are  given  below. 

The  x  screen  coordinate  of  the  zoom  (field  of  view,  or  fov)  indicator 
is  fixed.  The  y  screen  coordinate  varies  from  200  (at  8°  fov)  to  70 
(at  55°  fov).  The  input  missile  parameter  zoom  is  in  tenths  of 
degrees,  and  thus  ranges  from  80  to  550.  The  y  coordinate  is 
determined  from  Equation  A.l. 


y  -  200  - 


zoom  200  -  70 

-  -  8  *  - 

10  55  -8 


(A.l) 


=  zoom  *  -0.2766  +  222.128 


Likewise,  the  screen  x  coordinate  of  the  tilt  indicator  is  fixed,  while 
the  y  coordinate  varies  from  680  (at  +25°  tilt)  to  50  (at  —25°  tilt). 
The  input  missile  parameter  tilt  is  in  radians,  and  is  converted  to 
degrees  by  multiplying  it  with  the  RTOD  (Radians  TO  Degrees) 
constant  from  the  header  file  fogm.h.  The  y  coordinate  of  the  tilt 
indicator  is  calculated  as  shown  in  Equation  A. 2. 


y  -  50  + 


|[(fift  * DTOR)  +  25] 


680  -  50 
25  -  -25 


(A.2) 


=  tilt  *  721.92682  +  365 


The  pan  slider  bar  is  horizontal,  so  the  y  coordinate  is  fixed,  and 
the  x  coordinate  ranges  from  120  (at  -25°  pan)  to  750  (at  +25° 
pan).  Like  tilt,  the  pan  value  is  in  radians  and  must  be  converted 
to  degrees.  The  pan  indicator  x  coordinate  is  given  by  Equation 
A. 3. 


c  -  750 


/  r  750  -  120  ) 

\  (pan  *  DTOR)  -  25  '  - \ 

1  L  25  -  -25  / 


(A.3) 


=  pan  *  -721.92682  +  435 
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EXPLOSION. C 


Input:  None. 

Output:  None. 

Side  Effects:  None. 

Description:  The  explosion  routine  simulates  the  effect  of  a  missile  destroying  a 
target  by  rapidly  flashing  a  succession  of  red,  black,  and  yellow 
screens.  One  buffer  is  kept  black  to  pronounce  the  flash  effect,  and 
the  other  buffer  is  alternately  cleared  to  red,  yellow,  red,  yellow, 
and  red.  A  short  pause  with  a  cleared,  black  screen  is  provided 
before  the  routine  exits. 

FOGM.C 

Input:  Fogm  is  the  name  given  to  the  main  program  in  the  simulator.  It 

has  no  parameters,  but  gets  data  from  its  header  files  and  through 
the  readdata  routine.  Interactive  input  is  also  received  vial  the 
readcontrols  routine. 

Output:  None. 

Side  Effects:  None. 

Description:  The  fogm  program  consists  of  global  variable  declarations,  local 
variable  declarations,  system  initializations,  an  active  loop,  and 
some  exit  housekeeping.  The  initialization  portion  includes  reading 
in  the  DMA  elevation  data,  making  network  connection  (if  in  use), 
setting  the  IRIS  display  configuration,  defining  the  color  table 
entries,  building  all  of  the  graphical  objects  used  in  the  displays, 
and  computing  the  lighting  and  position  of  the  polygons  used  to 
produce  the  terrain  image.  Within  the  active  loop  is  some 
additional  initializations  and  the  flying  loop.  In  the  active  loop 
initializations,  the  dial  and  mouse  controls  are  reset  to  their  initial 
defaults,  and  the  display  buffers  are  loaded  with  the  images  that 
remain  unchanged  during  flight  simulation  (the  contour  map  and 
the  legend /instruction  box).  Control  is  then  passed  to  the  flying 
loop,  which  produces  the  flight  simulation  images  until  either  a 
target  is  hit  or  the  simulation  exit  command  is  received,  [f  a  target 
was  hit,  an  explosion  is  displayed  and  the  pre-launch  phase  of 
designating  launch  and  target  positions  is  re-entered.  If  all  three 
mouse  buttons  have  been  pressed,  the  display  is  cleared  and 
various  system  parameters  are  reset  to  provide  a  graceful  exit  from 
the  simulator. 


The  flying  loop  contains  the  subroutine  calls  that  produce  the 
simulation  of  flight.  First,  the  mouse  and  dials  are  checked  for 
control  input.  Then  the  targets’,  missile's,  and  lookat  reference 
point’s  positions  are  all  updated  based  on  the  elapsed  time  since 
the  previous  frame  and  the  appropriate  speeds.  View  bounds  is 
called  to  determine  which  one  kilometer  grid  squares  are  in  view, 
and  then  the  indicators  are  all  updated  to  show  the  new  control 
values,  missile  statistics,  and  view  area.  The  main  display  routine 
then  draws  the  appropriate  sections  of  the  terrain,  plus  cultural 
features  and  targets  where  appropriate.  Finally,  the  updated 
indicator  objects  are  drawn,  and  the  display  buffers  are  swapped  to 
display  the  newly  created  image. 

GAMMARAMP.C 

Input:  The  inputs  to  gammaramp  are  a  correction  factor,  a  color  table 

starting  index,  the  number  of  color  table  entries  (shades)  to  be 
defined,  red,  green,  and  blue  intensities  for  the  brightest  color  to  be 
defined,  and  finally,  red,  green,  and  blue  intensities  for  the  darkest 
color  to  be  defined. 

Output:  None. 

Side  Effects:  Gammaramp  has  the  side  effect  of  defining  entries  in  the  system 
color  table. 

Description:  Displayed  colors  do  not  correspond  linearly  to  the  numeric  red, 

green,  and  blue  intensity  values  that  are  used  to  produce  them.  If  a 
range  of  colors  (0  ..  # colors- 1)  is  defined  in  the  straightforward  way 
with  a  uniform  increment,  the  intensity  of  the  n  color  (7n)  is 
given  by  Equation  A. 4,  and  the  bright  colors  will  appear  more 
widely  spaced  than  the  dark  colors. 

Maxi  -  Mini 

In  =  n  * - +  Mini  (A.4) 

#  colors 

Gammaramp  avoids  this  by  using  a  power  function  to  increase 
spacing  between  the  dark  colors'  intensity  values  and  to  decrease 
the  intensity  increment  as  the  colors  get  brighter.  The  strength  of 

the  correction  is  determined  by  a  value  7,  which  is  constant  for  a 
given  range,  but  must  be  experimentally  determined  for  each  range 
that  differs  in  color  or  number  of  colors.  FOG-M  uses  a  7  value  of 
1.5.  The  intensity  of  the  n  color  in  a  gammaramp  created  table  is 
given  by  Equation  A. 5. 


n 


*  ( Maxi  -  Mini )  +  Mini 


(A. 5) 


GETTGT 

Input: 

Output: 

Side  Effects: 

Description: 


4  = 


(  #  colors  -  1  , 


POS.C 

The  input  to  get_tgt_po8  is  a  socket  number  for  Ethernet 
communication  (if  in  use),  a  boolean  indicating  designate/reject 
status,  the  index  of  the  currently  designated  target,  and  the 
“name”  of  the  tank  object. 

Output  is  the  new  X ,  Y,Z  position  coordinates  of  the  currently 
designated  target. 

Get  tgt_po8  updates  several  global  data  structures.  It  sets  the 
number  of  target  images,  updates  the  target  position  arrays,  and 
updates  the  array  of  target  object  names. 

The  primary  purpose  of  get  tgt  pos  is  to  move  the  targets  in  the 
simulation.  If  the  networking  capability  is  in  use,  the  target 
positions  for  the  next  frame  are  received  over  the  network.  When 
networking  is  not  in  use.  targets  are  moved  at  a  set  speed  of  fifteen 
knots,  and  reverse  course  when  they  reach  the  boundaries  of  the 
ten  kilometer  square  terrain  area.  As  explained  in  Chapter  VII,  an 
array  of  graphical  objects  is  defined  to  match  one  object  per  one 
hundred  meter  square  of  terrain,  and  this  array  is  also  used  as 
booleans  to  indicate  the  presence  or  absence  of  targets  in  the  one 
hundred  meter  grid  square.  Get_tgt_pos  begins  by  removing  each 
target  from  this  array.  New  target  positions  are  calculated  or 
received  over  the  network.  If  one  of  the  targets  has  been  “locked- 
onto,”  its  new  position  is  returned  to  be  used  as  the  current  aim 
point  for  the  missile.  This  is  easily  determined  if  networking  is  off 
because  the  designated  target’s  index  remains  the  same  and  the 
new  position  can  be  directly  accessed.  The  index  correspondence  is 
not  guaranteed  when  networking,  so  the  index  of  the  new  target 
whose  coordinates  are  closest,  to  the  oid  targeted  point  is  used. 

Targets  that  straddle  a  one  hundred  meter  grid  square  boundary 
must  be  drawn  on  top  of  both  ^or  possibiy  ail  four;  grid  squares  in 
order  to  avoid  being  partially  obscured  by  whichever  square  is 
drawn  last.  (The  target  must  be  drawn  immediately  after  the  grid 
square  on  which  it  rests  to  ensure  that  the  target  will  be  obscured 
when  it  should  be  by  terrain  drawn  in  the  foreground.)  Since  the 
calculation  of  boundary  intersection  requires  several  trigonometric 
functions  plus  an  allowance  for  the  distance  between  the  center  of 


the  tank  and  its  boundaries  (which  varies  with  the  direction  of  the 
tank),  a  simplifying  algorithm  is  used.  If  the  tank  is  close  enough 
to  a  boundary  that  the  most  distant  part  of  the  tank  might  cross 
the  boundary,  the  target  is  also  drawn  after  the  adjoining  grid 
square(s)  (see  Figure  7.3).  This  is  done  by  adding  a  “new”  target 
to  the  array  of  target  objects.  The  "‘new'’  target  object  is  drawn  at 
the  exact  same  location  in  the  three-dimensional  terrain,  but  it  is 
drawn  after  a  different  one  hundred  meter  grid  square,  so  it  will 
have 'different  target  object  array  indices,  and  be  in  a  separate 
target  object. 

After  all  of  the  targets  (originals  and  boundary  copies)  have 
updated  positions  and  target  object  array  indices,  objects  are 
added  to  the  target  object  array  as  described  in  Chapter  VII.  This 
array  is  then  used  by  the  terrain  display  routine  to  actually  draw 
the  targets. 

GND  LEVEL.  C 

Input:  Grid  level  takes  as  inputs  the  X  and  Z  coordinates  of  the  point  for 

which  the  elevation  is  desired. 

Output:  Gndjevel  returns  a  float  which  is  the  elevation  at  point  X  and  Z. 

Side  Effects:  None. 

Description:  Gndlevel  computes,  through  interpolation,  the  scaled  elevation  of 

any  point  within  the  terrain  boundaries.  A  calculation  is  done  to 
determine  which  gridtriangle  contains  the  point.  Then,  using  the 
known  elevations  at  the  vertices  of  the  triangle,  the  elevation  of  the 
point  is  found. 

IN  THIS  POLY.C 

Input:  In_this_poly  takes  the  following  inputs: 

-  An  array  of  points,  polygon ,  which  define  a  polygon.  (Note:  only 
the  X  and  Z  coordinates  of  the  points  are  used,  the  Y  value  is 

ignored). 

-  An  integer,  num  vertex,  that  is  the  number  of  vertices  in 

polygon. 

-  A  point,  pnt ,  that  is  to  be  tested.  (Note:  only  the  X  and  Z 
coordinates  of  the  point  is  used,  the  Y  value  is  ignored). 

Output:  In_this_poly  returns  a  boolean  which  is  TRUE  if  pnt  is  inside  the 

polygon  defined  by  polygon,  FALSE  otherwise. 


Side  Effects:  None. 


Description: 


Injtkisjtoly  is  a  function  which  tests  whether  a  point  is  inside  a 
given  polygon,  where  both  the  point  and  the  polygon  are  in  the  XZ 
plane.  The  algorithm  used  constructs  a  bounding  box  around  the 
polygon.  If  the  point  lies  outside  the  bounding  it  obviously  can 
not  be  inside  the  polygon.  If  the  point  lies  inside  the  bounding  box 
a  further  test  is  made.  A  line  is  constructed  from  a  point  outside 
the  bounding  box  to  the  point  to  be  tested.  Each  of  the  edges  of 
the  polygons  are  then  tested  to  see  if  they  intersect  the  constructed 
line  and  a  count  is  kept  of  the  number  that  do  intersect.  The 
point  lies  inside  the  polygon  if  and  only  if  the  constructed  line 
intersects  an  odd  number  of  the  polygon’s  edges. 


INIT  CTRLS.  C 


Input: 


Output: 


Side  Effects: 


Description: 


Init  ctrls  takes  as  inputs  the  initial  altitude  of  the  missile,  in  feet; 
the  initial  heading  of  the  missile  in  degrees;  and  a  boolean, 
greyscale,  which  is  TRUE  if  greyscaled  terrain  is  to  be  displayed 
and  FALSE  if  coior  terrain  is  to  be  displayed. 

Initctrls  has  as  outputs  the  initial  pan  angle  of  the  camera  in 
radians;  the  initial  tilt  angle  of  the  camera  in  radians,  and  the 
initial  zoom  setting  of  the  camera  in  tenths  of  a  degree. 

The  MOUSEX,  MOUSEY,  DIALO,  DIALl,  DIAL2,  and  DIAL3 
valuators  are  set  as  a  result  of  calling  this  routine. 

Init  ctrls' s  purpose  is  to  initialize  the  mouse  and  dial  valuators 
used  for  the  operator  controls.  The  initial  altitude,  heading,  and 
greyscale  valuator  settings  axe  passed  in  as  inputs.  The  pan,  tilt, 
and  field  of  view  settings  are  read  from  an  "include"  file  and  their 
values  passed  back  as  outputs. 


INIT  IRIS.C 


Input:  None. 

Output:  None. 

Side  Effects:  Calling  this  routine  sets  the  Iris  attributes  and  configures  the  Iris. 

Description:  Init_iris  accomplishes  the  following:  it  puts  the  Iris  into 

doublebuffer  mode,  sets  the  chunksize  (the  minimum  memory 
increment  used  in  objects),  sets  the  monitor  type  to  either  NTSC 
or  HZ60,  and  enables  backface  polygon  removal. 


None. 


Description: 


INIT  TGTS.C 

Input:  None. 

Output:  None. 

Side  Effects:  Inittgts  always  initializes  the  global  target  object  array  to  all 
zeros.  If  target  data  is  not  being  received  over  the  network, 
init  tgts  also  defines  ten  targets  by  setting  initial  values  in  the 
global  target  counter,  target  position  array,  and  target  direction 
array.  An  auxiliary  function  init_tgt  is  used  to  perform  the  actual 
update  of  the  global  arrays. 

INTERP  ELEV. C 

Input:  Interp  elev  takes  three  inputs,  each  an  array  of  X,  F,  and  Z 

coordinates,  representing  a  point.  One  array  is  the  start  point  of  a 
line,  the  second  array  is  the  end  point  of  a  line,  and  the  third  array 
is  a  point  along  the  line. 

Output:  Interp  elev  returns  a  float  that  is  the  elevation  value  of  the  point 

along  the  line. 

Side  Effects:  None. 

Description:  Interp  elev  returns  a  float  which  is  the  linear  interpolation  of  the 

F  (elevation)  coordinate  of  the  point  along  the  line,  based  on  the 
elevations  at  the  start  and  end  points  of  the  line. 

LIGHT  ORIENT. C 

Input:  Light  orient  takes  as  inputs  the  following: 

-  An  array  of  coordinates  for  the  polygon. 

-  An  integer,  num  coords ,  the  number  of  coordinates  in  the 
polygon. 

-  The  X,  Y ,  and  Z  coordinates  of  a  point  that  is  "behind”  the 
polygon  (an  interior  point). 

-  The  X ,  F,  and  Z  coordinates  of  a  light  source. 

-  The  minimum  and  maximum  color  map  indices  to  be  used  for 
■his  polygon. 

Output:  Light  orient  returns  the  color  map  index  of  the  color  to  use  in 

lighting  this  polygon.  It  also  reorders  the  polygon  array  (if 
necessary)  so  that  the  points  are  ordered  counterclockwise. 

Side  Effects:  None. 

Description:  Light  jorient  computes  a  lighting  for  a  polygon  based  on  Lambert’s 

cosine  law,  which  states  that  the  intensity  of  the  light  reflected 
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from  an  object  is  proportional  to  the  cos($),  where  $  is  the  angle 
of  incidence  of  the  light  ray.  (see  Figure  5.2).  Light _orient  also 
orders  the  vertices  of  the  polygon  in  a  counterclockwise  fashion  so 
that  backface  polygon  removal  can  take  place  (see  the  module 
description  for  npoly  orient). 


LINE  INTER2.C 


Input: 


Output: 


Side  Effects: 
Description: 


Line_inter2  takes  the  following  inputs: 

-  An  array  containing  the  X  and  Z  coordinates  of  the  start  point  of 
line_one  is  ignored.) 

-  An  array  containing  the  X  and  Z  coordinates  of  the  end  of 
line_one.  (Note:  a  three  element  array  is  used,  but  the  second,  Y 
coordinate,  element  is  ignored.) 

-  An  array  containing  the  X ,  Y ,  and  Z  coordinates  of  the  start  of 
line_two.  (Note:  a  three  element  array  is  used,  but  the  second.  Y 
coordinate,  element  is  ignored.) 

-  An  array  containing  the  X,  Y ,  and  Z  coordinates  of  the  end  of 
linetwo.  (Note:  a  three  element  array  is  used,  but  the  second,  Y 
coordinate,  element  is  ignored.) 

Line_inter2  returns  as  outputs: 

-  An  array  containing  the  X  and  Z  coordinates  of  the  intersection 
of  line_one  and  line_two.  If  the  lines  do  not  intersect  these  values 
are  undefined  not  considered  in  the  calculation). 

-  An  integer  which  can  be  interpreted  as  follows: 

0  -  the  lines  do  not  intersect. 

1  -  the  lines  intersect,  but  the  intersection  uses  an 
extension  of  at  least  one  of  the  lines  past  its  start  or 
end  points. 

2  -  the  lines  intersect,  and  the  intersection  occurs 
between  the  input  start  and  end  points  of  both  lines. 

None. 

Line  intcr2  computes  the  point  of  intersection  between  two  lines 
in  the  XZ  plane.  The  type  of  Intersection,  as  explained  above  in 
"Output"  is  also  determined.  Througnout  rhe  routine,  three 
element  arrays  are  used  for  compatibility  with  other  routines.  The 
second,  F,  coordinate  is  not  considered  in  any  of  the  calculations. 


MAKEINDBOX.C 


Input: 


None. 


SB 


Output: 


Makeindbox  returns  a  graphical  object  “name,”  tags  for  editing  the 
speed,  direction,  altitude,  and  designate/reject  readouts,  and  tags 
for  editing  the  zoom,  pan,  and  tilt  indicators. 

Side  Effects:  None. 

Description:  Makeindbox  generates  a  graphical  object  that  contains  both  the 

indicator  box  in  the  middle  of  the  displays  on  the  right  side  of  the 
screen  and  the  “heads-up”  display  that  is  superimposed  on  the 
terrain  image  (Figure  6.8).  The  object  consists  almost  entirely  of 
straightforward  line  and  character  string  drawing  commands,  but 
there  are  two  interesting  points.  First,  within  a  single  object,  there 
are  two  different  coordinate  systems:  one  for  the  indicators 
superimposed  on  the  terrain,  and  another  for  the  separate  indicator 
box.  This  is  accomplished  with  an  ortho2  call  for  each  coordinate 
system,  and  by  bracketing  each  ortho2  with  pushmatrix  and 
popmatrix  commands.  Note  that  the  heads-up  display  is  truly 
superimposed;  it  is  specified  in  two-dimensional  screen  coordinates 
as  opposed  to  the  three-dimensional  terrain  coordinates. 

The  second  interesting  aspect  is  the  movement  of  the  slider  bar 
indicators.  Drawing  the  indicators  as  polygons  would  require  a 
sequence  of  pushmatrix ,  translate,  and  popmatrix  calls  for  each 
indicator,  with  movement  achieved  by  editing  the  translate  call.  To 
avoid  all  of  this  matrix  movement  and  multiplication,  the 
“triangle”  of  the  indicator  is  actually  an  overlapped  line  that 
“fills”  the  triangle  by  spiraling  inwards.  The  line  is  drawn  relative 
to  the  indicated  point,  with  each  segment  of  the  line  specified  as 
offsets  from  that  initial  point,  rather  than  as  absolute  coordinates 
(Figure  A.l).  Movement  of  an  indicator  triangle  defined  in  this 
way  is  achieved  by  editing  the  parameters  of  a  move  2  call  in  the 
object,  which  sets  the  current  graphics  drawing  position  to  the 
indicated  point  on  the  slider  bar  scale.  Makeindbox  is  called  once 
by  fogm  before  the  flying  loop  is  entered,  and  then  the  object  is 
edited  (to  update  the  indicator  values)  and  called  (to  display  it) 
every  frame. 


MAKEINSTRBOX.C 
Input:  None. 

Output:  Makeinstrbox  returns  the  name  of  an  object  to  fogm. 

Side  Effects:  None. 


Description:  Makeinatrbox  creates  the  object  that  produces  the  display  in  the 

lower  right  of  the  screen  (Figure  6.8)  during  flight  simulation.  This 
display  contains  the  legend  for  the  FOG-M  controls  and  the  flight 
parameters  they  affect.  Makeinatrbox  is  called  once  by  fogm  to 
create  the  object,  and  then  the  object  is  called  twice  per  flight  to 
put  the  image  into  each  buffer.  Note  that  writemasks  are  not 
necessary  as  they  are  with  makemap  and  makenavbox,  because 
nothing  else  writes  to  the  instruction  box  portion  of  the  screen 
during  flight.  The  image  thus  remains  undisturbed  in  the  bitplanes 
despite  the  changes  in  other  screen  areas. 

MAKEMAP. C 

Input:  The  input  to  makemap  is  the  globally  defined  array  of  elevation 

and  vegetation  values,  gridpixel. 

Output:  The  output  from  makemap  is  a  graphical  object  “name.”  which  is 

returned  to  fogm. 

Side  Effects:  None. 

Description:  Makemap  generates  the  object  containing  the  contour  map  and 

grid  that  appear  full  screen  during  the  pre-launch  phase,  and 
appear  in  the  upper  right  corner  of  the  screen  during  flight 
simulation  (Figure  4.1).  The  map  is  produced  using  the 
methodology  described  in  Chapter  IV.  Fogm  calls  the  object 
returned  by  drawcontoxir  twice,  in  order  to  place  the  map  image  in 
both  buffers.  The  image  is  then  protected  from  overwrite  by  a 
writemask.  Fogm  also  passes  the  object  name  to  prelaunch ,  which 
uses  it  in  much  the  same  way  as  fogm. 

MAKESCREENS.C 

Input:  None. 

Output:  Makeacreens  returns  an  array  of  objects:  instruction  panel, 

statistics  box,  flight  path  between  launch  and  target  endpoints, 
and  the  three  welcome  screens,  plus  tags  to  update  the  statistics 
and  flight  path. 

Side  Effects:  None. 

Description:  Makeacrcens  builds  all  of  the  objects  (mostly  screens  of  text)  that 

are  used  by  prelaunch. 


MAKETANK.C 

Input:  None. 

Output:  Maketank  returns  the  name  of  an  object  containing  a  single  tank, 

drawn  around  the  origin. 

Side  Effects:  None. 

Description:  Maketank  builds  a  object  that  consists  solely  of  the  drawing 

commands  to  produce  a  single  tank.  The  tank  is  thirty-two  feet 
long,  ten  feet  high,  and  ten  feet  wide.  Its  center  bottom  is  at  the 
origin  (coordinates  0.0.01.  with  its  left  side  on  the  plane  Z  —  -5.  its 
back  on  the  plane  X  =  -15,  its  bottom  on  the  plane  Y  =  0,  and  it 
faces  to  the  right  along  the  positive  x  axis.  For  each  of  the  twenty 
polygon  faces  that  make  the  tank,  the  X,  Y ,  and  Z  coordinates  of 
each  polygon  vertex  are  stored  in  an  array,  passed  to  lightorient , 
and  then  drawn  with  polf ,  the  filled  polygon  drawing  command. 
Lightorxe.nt  ensures  *he  vertices  are  ordered  counter-ciockwise  in 
the  array  (with  respect  to  an  interior  point)  for  backface  polygon 
removal,  and  then  calculates  the  appropriate  color  for  the  polygon 
using  the  same  lighting  model  that  is  used  for  the  terrain  (see 
Chapter  V). 

NEAREST  TGT.C 

Input:  Nearest  tgt  takes  as  inputs  the  X,  Y ,  and  Z  coordinates  of  the 

missile  position,  and  the  X,  Y,  and  Z  coordinates  of  the  camera’s 
look-at  position.  (The  end  points  of  the  line  of  sight  vector). 

Output:  Nearest  tgt  returns  as  output  an  integer,  tgt  idx,  which  is  the 

target  index  of  the  target  that  is  closest  to  the  line  of  sight  vector. 

Side  Effects:  None. 

Description:  For  each  of  the  existing  targets,  nearest  tgt  computes  the  distance 

between  the  target  and  the  line  of  sight  vector.  It  returns  the 
index  of  the  target  that  was  found  to  be  closest.  In  the  case  of  two 
targets  which  are  the  same  distance  apart,  the  highest  index  value 
will  be  returned. 

NPOLY  ORIENT. C 

Input:  Npoly  orient  takes  as  input: 

-  An  integer,  num  coords,  that  is  the  number  of  vertices  in  the 
polygon. 

-  An  array  containing  the  coordinates  of  the  polygon. 

-  The  X,  Y ,  and  Z  coordinates  of  a  point  that  is  "behind"  the 


polygon  (an  "interior"  point). 

Output:  Npoly  _orient  returns  as  output  an  integer  which  is  interpreted  as: 

1  -  the  vertices  of  the  polygon  are  ordered  clockwise. 

2  -  the  vertices  of  the  polygon  are  ordered 
counterclockwise. 

Side  Effects:  None. 

Description:  Npoly  _orient  determines  if  the  polygon  is  ordered  clockwise  or 

counterclockwise  by  computing  two  points:  one  along  the  normal 
vector  and  the  other,  the  same  distance  from  the  polygon,  but 
along  the  vector  in  the  direction  opposite  the  normal.  Next  the 
distance  between  these  points  and  the  "interior"  point  is 
computed.  If  the  "interior"  point  is  closer  to  the  point  along  the 
normal  vector,  the  polygon  is  ordered  clockwise,  otherwise  the 
polygon  is  ordered  counterclockwise. 

PRELAUNCH. C 

Input:  The  input  to  prelaunch  is  two  arrays.  The  first  contains  objects, 

and  the  second  contains  tags  for  editing  those  objects. 

Output:  Prelaunch  returns  the  .Y,  Y.  and  Z  coordinates  of  the  missile’s 

designated  launch  position,  and  the  initial  direction  of  flight  for  the 
missile.  This  direction  is  returned  in  both  radians  and  compass 
degrees  (Figure  7.1). 

Side  Effects:  None. 

Description:  Prelaunch  first  provides  three  screens  of  introductory  information. 

Each  screen  is  an  object  defined  by  makescreens.  After  those,  the 
user  is  presented  with  a  full  screen  contour  map  of  the  ten 
kilometer  by  ten  kilometer  area  available  for  overflight.  Mouse- 
selected  points  define  the  missile’s  initial  position  and  direction  of 
flight,  and  are  displayed  on  top  of  the  map.  The  map  is  writemask 
protected,  so  it  is  only  drawn  twice  (once  for  each  buffer)  even 
though  the  flight  path  is  repeatedly  drawn  and  erased  on  top  of  the 
map.  The  flight  path  is  made  to  act  like  a  rubber  band  between 
the  launch  and  cursor  positions  by  repeatedly  editing  of  the 
positions  in  the  object  containing  the  flight  path  line  drawtng 
commands.  Once  the  flight  path  is  confirmed,  the  launch  position 
and  heading  are  returned  to  the  fogm  program. 


RANDNUM.C 


Input: 

Output: 

Side  Effects: 

Description: 


Randnum  uses  the  global  random  number  seed. 

Randnum  returns  a  floating  point  random  number. 

The  global  seed  value  used  by  randnum  is  updated  during  every 
invocation. 

Randnum  is  a  linear  congruential  pseudo-random  number 
generator.  The  algorithm  is  a  modified  version  of  the  one  given  by 
Sedgewick  [Ref.  13].  It  uses  a  a  special  piecewise  multiplication 
routine  mult  to  preserve  the  low-order  digits  of  the  newly 
generated  seed  even  in  case  of  overflow.  The  value  returned  is  the 
new  seed,  scaled  to  fall  between  zero  and  one,  inclusive.  The 
random  numbers  are  used  in  fogm  to  vary  the  point  on  the  tank 
that  the  missile  aims  for.  This  simulates  the  variance  in  impact 
point  that  results  from  the  optical  homing  of  the  real  missile. 


RANDSEED.C 


Input: 

Output: 

Side  Effects: 
Description: 


Randseed  takes  a  long  integer  as  input. 

None. 

Randseed  updates  the  global  random  number  seed  value. 

The  pseudo-random  number  generator  implemented  in  randnum 
always  returns  the  same  string  of  numbers  when  it  starts  with  a 
given  seed  value.  Randseed  provides  the  means  to  change  that 
initial  seed  value  so  that  different  program  runs  will  have  different 
strings  of  “random”  numbers. 


READCONTROLS.C 

Input:  The  inputs  to  readcontrols  are  the  global  X ,  Y,  and  Z  random 

offset  values  for  the  aim  point  on  the  target,  the  current 
designate/reject  status,  and  the  black-and-white  versus  color 
boolean  greyscale. 

Output:  All  of  the  user-commanded  control  -'alues  are  ourput  from 

readcontrois:  missile  speed,  heading  and  altitude,  camera  pan.  tilt, 
and  zoom  angles,  plus  designate/ reject  status,  greyscale  status. 
Readcontrols  also  returns  values  for  the  booleans  that  control  the 
active  and  flying  loops. 

Side  Effects:  When  a  target  is  first  designated,  readcontrols  calls  randnum  and 
updates  the  global  target  aim  offsets  randx,  randy,  and  randz. 


Description:  Readeontrols  checks  the  status  of  all  of  the  valuators  that  provide 

input  to  the  FOG-M  simulator,  and  performs  scaling,  units 
conversion,  and  immediate  processing,  as  appropriate.  It 
determines  whether  to  accept  or  reject  a  “designate”  command, 
based  on  the  color  index  of  the  pixel  at  the  center  of  the  screen.  (If 
a  tank  is  in  the  crosshairs,  the  color  index  will  be  from  the  tank's 
color  ramp,  and  a  designate  command  will  be  accepted.  Otherwise, 
a  designate  command  will  be  ignored.) 

READDATA.C 
Input:  None. 

Output:  None. 

Side  Effects:  Readdata  fills  the  global  array  gridpixel. 

Description:  Readdata  opens  and  reads  the  values  from  the  terrain  elevation 

data  file  and  stores  the  values  in  the  gridpixel  array.  Note  that  the 
elevation  data  file  is  arranged  in  a  format  as  discussed  in  Chapter 
III.  The  gridpixel  array  is  arranged  in  straight  rows  and  columns 
analogous  to  the  geographic  positions  of  the  data. 

ROAD  BOUNDS. C 

Input:  Road  bounds  takes  as  input  the  following: 

-  Three  arrays  [pt  1,  pt  2  and  pt  3)  containing  the  X  and  Z 
coordinates  of  three  points  along  the  centerline  of  the  road.  The 
line  segment  from  pt  1  to  pt 2  defines  the  first  segment  of  the  road. 
The  segment  from  pt  2  to  pt 3  defines  the  next  segment  of  the  road. 

-  A  float,  width,  which  is  the  width  of  the  road  in  feet. 

Output:  Road  bounds  returns  the  following  as  outputs:  -  Four  arrays 

{leftjpt  1,  right _pt\,  leftjpt 2,  and  right _pt2)  which  contain  the  X 
and  Z  coordinates  of  the  first  segment’s  left  and  right  sides.  The 
left  side  runs  from  leftjptl  to  lcftjpt2  and  the  right  side  runs  from 
right  pt  1  to  right  pt 2. 

-  Four  integers,  first  xgrid.  first  zgrid.  last  xgrid  and  last  zqrid. 
which  are  the  indices  of  the  bounding  box  surrounding  the  irst 

road  segment  (see  Figure  8.2). 

Side  Effects:  None. 

Description:  Given  three  points  along  the  center  line  of  the  road,  and  the  road’s 
width,  roadjbounds  computes  the  start  and  end  coordinates  for  the 
first  segment’s  left  and  right  sides.  The  end  coordinates  are 
computed  as  the  intersection  of  the  first  segment’s  left  (or  right) 
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side  with  the  second  segment’s  left  (or  right)  side.  This  insures 
that  adjoining  segments  will  meet  cleanly.  The  second  function  of 
road_bounds  is  to  compute  a  bounding  box  around  the  first  road 
segment.  This  box  is  defined  as  the  row  indices  of  the  northern 
and  southern  most  gridsquares  that  the  road  segment  intersects, 
and  the  column  indices  of  the  eastern  and  western  most  gridsquares 
that  the  road  segment  intersects  (See  Chapter  VIII  for  a  more 
detailed  discussion). 


SORT  ARRAY.C 

Input:  Sort  array  takes  as  inputs: 

-  An  array  of  points,  pnts. 

-  An  integer  that  is  the  number  of  entries  in  the  pnts  array. 

-  A  boolean,  which  is  TRUE  if  the  array  should  be  sorted  in 
descending  order,  FALSE  if  the  array  should  be  sorted  in  ascending 
order. 

-  The  index  number  of  the  coordinate  that  is  the  sort  key:  0  for  the 
X  coordinate.  I  for  the  Y  coordinate,  and  2  for  the  Z  coordinate. 


Output: 

Side  Effects: 


Sortjarray  returns  the  array  pnts  with  the  points  sorted  according 
to  the  input  parameters. 

None. 


Description:  Sort  array  performs  a  simple  "bubble-sort”  of  the  input  points 

according  to  the  input  parameters. 


UP  LOOK  POS.C 

Input:  UpJook_pos  takes  the  following  as  inputs: 

-  The  heading  of  the  missile  in  radians. 

-  The  pan  angle  of  the  camera  in  radians. 

-  The  tilt  angle  of  the  camera  in  radians. 

-  The  X,  Y,  and  Z  coordinates  of  the  missile’s  position. 

-  The  X,  y,  and  Z  coordinates  of  the  locked-on  target  (if  any). 

-  A  boolean  which  is  TRUE  if  the  missile  is  locked-on  a  target. 
FALSE  otherwise. 

Output:  Up_look_pos  returns  as  outputs  the  X,  Y,  and  Z  coordinates  of  the 

camera’s  look-at  position. 

Side  Effects:  None. 

Description:  UpJook_position  computes  a  point  along  the  camera’s  line  of 

sight.  If  the  missile  is  locked  on  a  target,  the  look-at  position  is  the 
locked-on  target’s  position.  Otherwise  it  is  any  point  along  the 
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camera’s  line  of  sight.  See  Chapter  VI  and  Figure  6.2  for  a  more 
detailed  discussion. 

UP  MSL  POSIT.C 

Input:  Up  msl  posit  takes  as  inputs: 

-  The  heading  of  the  missile  in  radians. 

-  The  speed  of  the  missile  in  knots. 

-  The  X ,  Y ,  and  Z  coordinates  of  the  missile’s  position. 

-  The  X,  Y ,  and  Z  coordinates  of  the  locked-on  target  (if  any). 

-  A  boolean  which  is  TRUE  if  the  missile  is  locked-on  a  target, 
FALSE  otherwise. 

Upjnsljposit  returns  as  outputs: 

-  The  new  heading  of  the  missile  in  radians,  if  it  was  changed  to 
track  a  locked-on  target. 

-  The  new  heading  of  the  missile  in  degrees  measured  in  the 
compass  convention. 

-  A  boolean  which  is  TRUE  if  the  missile  is  still  flying  (has  not  hit 
a  target),  and  FALSE  if  the  missile  has  hit  the  target. 

None. 

Description:  Up  msl  posit  calculates  a  new  missile  position  for  the  next  frame. 

The  new  position  is  either  based  on  the  commanded  direction, 
speed,  and  altitude  (when  the  missile  is  NOT  locked  onto  a  target), 
or  the  commanded  speed  and  the  direction  to  the  target  (if  the 
missile  is  locked  onto  a  target).  For  a  detailed  discussion  of  the 
routine,  see  Chapter  VI. 

VIEW  BOUNDS.C 

Input:  View  bounds  takes  as  inputs  the  X,  Y ,  and  Z  coordinates  of  the 

missile’s  position;  the  X ,  Y ,  and  Z  coordinates  of  the  camera’s 
look-at  position;  and  the  field  of  view  (zoom)  value. 

Output:  View  bounds  returns  as  outputs  the  row  indices  of  the  northern 

and  soiithem  most  gridsquares  to  be  drawn,  and  the  column 
indices  of  the  western  and  eastern  most  gridsquares  to  be  drawn. 

Side  Effects:  None. 

Description:  The  purpose  of  view Jbounds  is  to  construct  a  bounding  box  around 

the  gridsquares  which  are  to  be  drawn.  The  box  is  constructed  by 
extending  the  line  of  sight  vector  down  until  it  intersects  the 
minimum  elevation  plane.  The  view  bounds  extends  20 
gridsquares  north,  south,  east,  and  west  of  this  intersection  point. 


Output: 


Side  Effects: 


e  missile’s  position  is  not  within  the  bounds,  the  bounds  are 
ded  to  include  the  missile’s  position.  For  a  more  detailed 
ssion,  see  Chapter  VI  and  Figure  6.5 


APPENDIX  B  -  SOURCE  LISTINGS 


BUILD  ROAD 


^include  "stdio.h" 

#  include  "fogm.h" 

#  include  "files.h" 

^include  "gl.h" 

#include  "math.h" 

fdefine  X  0 

#define  Y  1 

#define  Z  2 

#define  DIAGONAL  0 

^define  HORIZONTAL  1 
f define  VERTICAL  2 

fdefine  LOWER  0 
^define  UPPER  1 

build  road  () 

{ 

extern  Object  road[99](99|; 
extern  short  gridpixel[100||l00j; 

FILE  *fp,  *fopen(); 

float  road  width;  /*  road  width  if  feet  */ 

int  numpts;  /*  number  of  data  points 

for  the  road  seqment  */ 

int  segnum  =  0; 
char  temp|l00); 
int  cnt,  i,  j; 

int  vertex_cnt,  num_duplicates; 
float  gnd_level(); 
float  elev; 

float  ptl[3],  pt2(3],  pt3|3|; 

float  nw_corner[3],  ne_corner[3],  sw  corner;3],  se_corner|3]; 
float  right_ptl[3|,  right_pt2(3|; 
float  left  pt l  3!.  left _pt2' 3' ; 

float  north  bound,  south  bound,  “asc  bound,  -.vest  bound: 
float  delta  x.  delta  v. 

float  seg  dir; 

int  ne_flag,  nw_flag,  se_flag,  sw  flag; 
int  xgrid,  zgrid; 

int  first  xgrid,  last  xgrid,  first  zgrid,  last  zgrid; 
float  poly  1  [  10]  [ 3) ; 


frontbufTer(TRUE); 

fp  =  fopen(ROAD_FILE,"r"); 


hile  (fscanf(fp,  "%e",  icroadwidth)  !  =  EOF)  { 
fscanf(fp,  "%d",  &num_pts); 
fscanfjfp,  "%e  %e",  &ptl!Xl,  Aptl(Zi); 
fscanf(fp,  "%e  %e",  3zpt2jX],  &pt2|Zj); 

delta  _x  =  pt2(XI  -  ptlfX!; 
delta_z  =  pt2[Z]  -  pc  1  [Z j ; 
segdir  =  atan2(delta_z,  delta  x); 

left_ptl[X]  =  ptl(X]  +  (cos(seg_dir  +  HALFPI)*road_width/2.0); 
right_ptl(XJ  =  ptl(X]  +  (cos(seg_dir  -  HALFPI)*road_width/2.0); 
left_ptl[Z]  =  ptl[Z]  +  (sin(seg_dir  +  HALFPI)*road_width/2.0); 
rightptllZj  -  ptl[Zj  (sin(seg_dir  -  HALFPI)  *  road_width/2.0); 
for  (cnt  =  3;  cnt  <=  num_pts  +  1;  ++cnt)  { 
if  (cnt  <=  num_pts)  { 

fscanf(fp,  "%e  %e ",  cfeptSfXj,  <kpt3[Z|); 

} 

else  { 

pt3|X|  =  pt2|X|; 
ptSiZ]  =  pt2'ZI; 

} 

/*  print  new  road  segment  number  on  title  screen  */ 

segnum  +=  1; 

pushmatrix(); 

ortho2(0.0,  1023.0.  0.0,  767.0); 
viewport  (0.1023. 0,767); 

sprintf(temp,  "Building  road  segment;  %d%",  segnum); 
color(BLUE); 

rectf( 780.0,  20.0,  1010.0,  30.0); 

color(CYAN); 

cmov2i(780,  20); 

charstr(temp); 

popm*trix(); 

/*  determine  the  boundaries  of  this  road  segment  */ 
road_bounds(ptl,  pt2,  ptS,  road  width,  left  ptl,  rightptl, 
left_pt2,  right_pt2,  Afirst  xgrid, 

Afirst  zgrid,  Alast  xgrid,  Adast_zgrid); 

for  (xgrid  =  firstxgrid;  xgrid  <=  last  xgrid;  ++xgrid){ 

for  (zgrid  =  first  zgrid;  zgrid  <=  last  zgrid;  ++zgrid){ 
neflag  =  FALSE; 
nwflag  =  FALSE; 
swflag  =  FALSE; 
se  flag  =  FALSE, 
vertex  cnt  -  -l; 

<*ast  bound  =  i  float)(xgrid  -  1)  *  FT  100M: 

west_bound  =  (8oat)(xgrid)  *  FT  100M; 
north_bound  =  (float)  (zgrid  +  1)  *  FT  100M; 
south_bound  =  (float) (zgrid)  *  FT  100M; 

sw_corner[X]  =  west_bound; 
sw_corner[Z]  =  south  bound; 
elev  =  gridpixeljzgridjjxgrid]  it  elev  mask; 
sw_corner(Y|  =  pow(elev,  ALTSCALE); 
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se  cornerlX!  =  east  bound; 

se_corner[Z]  —  south_bound; 

elev  =  gridpixel!zgrid](xgrid+l)  St  elevmask; 

»e_corner[Yl  =  pow(elev,ALTSCALE); 

nw  cornerlX)  =  west  bound; 

nw  cornerjZ!  =  north  bound; 

elev  =  gridpixeljzgrid+ljjxgrid]  St  elev  mask; 

nw_corner[Y|  =  pow(elev,ALTSCALE); 

ne_corner(X]  =  east  bound; 

ne_cornerZ!  =  north  bound; 

elev  =  gridpixel[zgrid+ll[xgrid+l]  St  elev_nrtask; 

ne_cornerjYj  =  pow(elev,  ALTSCALE); 

/*  determine  points  of  intersection  between  the  left  and 

right  sides  of  the  road  and  the  eastern  grid  boundary 
and  add  these  points  to  the  polygon  vertex  array  * 

do_boundary(VERTICAL,  UPPER,  xgrid,  zgrid,  se_corner,  ne_corner, 
left  ptl,  left_pt2,  rightptl,  right_pt2,  4tse  flag, 
fcnetlag,  poly  I.  icvertex  _cnt); 

!*  determine  points  of  intersection  between  the  left  and 

right  sides  of  the  road  and  the  northern  grid  boundary 
and  insert  these  points  into  the  polygon  vertex  array  */ 
do_boundary(HORIZONTAL,  UPPER,  xgrid,  zgrid,  ne  corner, 
nw  corner,  leftjptl,  left  pt2,  right  ptl, 
right_pt2,  itne  flag,  tnw  flag,  polyl,  ivertex  cnt); 

/*  determine  points  of  intersection  between  the  left  and 
right  sides  of  the  road  and  the  diagonal  and 
insert  these  pointsinto  the  polygon  vertex  array  */ 

do_boundary(DIAGONAL,  UPPER,  xgrid,  zgrid,  nw  corner,  se  corner, 
left_ptl,  left_pt2,  right  ptl,  right_pt2,  &nw  flag, 

&se_flag,  polyl,  ^vertex  cnt); 

/*  remove  duplicate  entries  from  the  polygon  array  */ 

num_duplicates  =  0; 

for  (i  =  1;  i  <=  vertex_cnt;  ++i)  { 

if  ((poly  l- i  f)  -  ~  potv  I:  i- 1  0:)  St  ft 
(polvl  i,  2!  =  =  polyili-l!  2’))  ! 

for  (j  ■=  i:  j  <  vertex  cnt  -  num  iuoiicar.es:  — j|  \ 
polyl|j)[0|  =  polyl(j+l|[0|; 
poly  1  (jj  ( 1  j  =  poly  1  |j-t- 1  ]  j  1  ] ; 

Poly  l[jj(2j  =  polyljj  +  lj|2]; 

} 

num  duplicates  -*-  =  1; 

} 

} 

vertex_cnt  -=  num  duplicates; 


if  (vertex_cnt  >  0)  {  /  add  polygon  to  grid_object  */ 
if  (road[zgrid|  [xgrid;  !=  0)  { 

editobj  (road  [  zgrid]  (xgrid  ] ) ; 

} 

else  { 

road[zgrid|[xgrid]  =  genobj(); 
makeobj(roadlzgridj[xgridi); 

} 

color(ROADGREY);  * 
polf(vertex_cnt  +1,  &polyl[0][0]); 
linewidth(S); 

poly  (vertex  _cnt  —  1.  Izpoly  1  [0]  (Oj ) ; 
closeobj(); 

} 

vertexcnt  =  -1; 
neflag  =  FALSE; 
nw_flag  =  FALSE; 
sw_flag  =  FALSE; 
seflag  =  FALSE; 

/*  determine  points  of  intersection  between  the  left  and 

right  sides  of  the  road  and  the  southern  grid  boundary 
and  insert  these  points  into  the  polgon  vertex  array  * 
do_boundary(HORIZONTAL,  LOWER,  xgnd,  zgrid,  swcorner, 
se  corner,  left  ptl,  left_pt2,  rightptl, 
right_pt2,  tswjag,  <kse__8ag,  polyl,  Izvertex  cnt); 

/*  determine  points  of  intersection  between  the  left  and 
right  sides  of  the  road  and  the  diagonal  and 
add  these  points  to  the  polygon  vertex  array  */ 

do_boundary(DIAGONAL,  LOWER,  xgrid,  zgrid,  se_corner,  nw_corner, 
left  ptl,  left_pt2,  right  ptl,  right_pt2,  icse  flag, 
itnwflag,  polyl,  izvertex  cnt); 

t*  determine  points  of  intersection  between  the  left  and 

right  sides  of  the  road  and  the  western  grid  bound 
and  add  these  points  to  the  polygon  vertex  array  */ 

do_boundary{ VERTICAL,  LOWER,  xgrid,  zgrid,  nw  corner,  sw  corner, 
left  ptl,  left_pt2,  right  ptl,  right_pt2,  &nw_8ag, 

&sw  flag,  polyl,  .^vertex  cnt); 

remove  duplicate  entries  trom  the  polygon  array  * 

numdupiicates  =  0; 

for  (i  =  1;  i  <=  vertex  cnt;  ++i)  { 

if  ((polyl(ij[0j  ==  poly l[i- lj [Oj)  kL 

(poly  1  [i] [2]  ==  poly l[i-l]|2)))  { 

for  (j  =  i;  j  <  vertex_cnt  -  num_duplicates;  ++j)  { 

Poly  1  (j  1  [Oj  =  polyl[j+lj(0); 
poly  1  [jj|  1  j  =  polyljj  + 1  j  [  1  j ; 


poly  1  [j  1(2)  =  polyl(j+lj[2j; 


} 

numjduplicates  +=  1; 

} 

} 

vertex  _cnt -=  num  duplicates: 
if  (vertex_cnt  >  0)  {  /'*  add  polygon  to  grid  objec 
if  (road[zgridj[xgrid|  !=  0)  { 

editobj(road[zgrid][xgridj); 

} 

else  { 

roadfzgridjfxgridj  =  genobj(); 
makeobj(roadjzgridjjxgridj); 

} 

color(ROADGREY); 
polf(vertex_cnt  +1,  Atpoly l[0]  [0] ) ; 
linewidth(S); 

poly(vertex_cnt  +  1,  &polyl|0][0j); 
closeooj(); 

> 

} 

} 

right  ptl|X|  =  right  _pt2(X'; 
nghtptllZl  =  right_pt2jZI; 
left  _pt  1 1 X  j  =  left  _pt2|  XI ; 

left _ ptl[ZJ  =  left _ pt2[Z{; 

ptl  [X]  =  pt2[X|; 
ptljZ]  =  pt2[Zj; 
pt2|X]  =  pt3|X|; 
pt2(Z|  =  pt3(Zj; 

} 

} 

fclose(fp); 

frontbuffer(FALSE); 


BU1LDTERRAIN 


/*  buildterrain.c  -  this  function  builds  objects  representing  1km  grid  squares 
in  S-D,  with  each  grid  square  generating  4  objects,  identical  except  for 
order  of  drawing  */ 

#include  "gl.h"  /*  get  the  graphics  defs  */ 

^include  "device.h"  /*  get  the  graphics  device  defs  *  j 
^include  "fogm.h"  /*  default  constants  */ 

^include  "math.h"  /*  math  function  declarations  */ 

buildterrainQ 

{ 

/*  array  of  data  points  to  build  the  terrain  *  / 
extern  short  gridpixel(100l[100|; 

extern  ttoat.  savetria.ngle' 99!  ‘991  [2 ! ! 3 1  i  3 j ; 

extern  long  gridcolor[99][99|; 

extern  Object  targec|99lj99l; 

extern  float  ground_planei4i;3!; 

extern  long  gnd  plane  color; 

float  gndplaneht; 

Coord  trianglel(3|[3|,  triangle2[3|[3j;  /*  polygon  coordinates  * / 

short  xgrid,  zgrid;  J*  indexes  into  the  grid  object  array  */ 

short  endrow,  endcol;  /*  miscellaneous  indexes  etc  */ 

int  row,  col; 

float  ax,ay,az;  /*  interior  point  for  use  in  the  lightpoly  function  */ 

float  lx,ly,lz;  /*  position  of  light  source  in  lightpoly  function  */ 

*  min  and  max  colormap  indexes  for  lighting  the  poly  * 
long  'toiormin.  toiormax: 

j*  color  index  to  use  returned  by  the  lightpoly  function  */ 
long  colortouse,  colorl,  color2; 

char  temp[50|;  /*  character  string  for  countdown  */ 

float  x,y; 
float  gammacorr; 

long  rampamax,  rampamin,  rampbmax,  rampbmin; 


133 


i.i  »-t  t.i  m  ♦.*  ■»>  ».i,' 


TOmmntrawgra’j™ 


int  startrow,  started,  coordidx,  vertex; 


lx  =  500  *  FT_100M;  /  *  direction  of  light  source  */ 

ly  =  100000  *  FT100M; 

It  =  ly; 

frontbuffer(TRUE);  /*  write  to  front  buffer 

/*  compute  color  for  groundplane  polygon  */ 
gnd  plane  ht  =  pow((  float)  MIN,  ALTSCALE); 
ground _planei0l|0]  =  -NUMXGRIDS  *  FEETPERGRID: 
ground_plane(0|[l|  =  gndplaneht; 
ground_planej0][2]  =  NUMZGRIDS  *  FEETPERGRID; 

ground _plane[ l] (0)  =  2.0  *  NUMXGRIDS  *  FEETPERGRID; 

ground_plane[l|[l]  =  gnd_plane_ht; 

ground  plane|l|[2|  =  NUMZGRIDS  *  FEETPERGRID; 

ground _plane,2|(0)  =  2.0  *  NUMXGRIDS  *  FEETPERGRID; 
ground_plane(2][l)  =  gnd_plane_ht; 

ground3lane(2]|2]  =  -2.0  *  NUMZGRIDS  *  FEETPERGRID; 

ground  piane:3!,0|  =  -NUMXGRIDS  *  FEETPERGRID; 
ground  plane;  3 { ;  1 !  =  gnd  piane  ht; 

ground  pianei3':2j  =  -2.0  *  NUMZGRIDS  *  FEETPERGRID; 

lightorient (ground  plane, 4, 0. 0,0. 0,0.0, lx, ly,lz, 256, 461,  Jdgndplanecolor); 

/*  compute  coordinates  and  colors  for  triangles  and  store  in  global 
variable  savetriangle  for  later  display  *  j 

for  (col  =  0;  col  <  99;  ++col)  { 

/*  print  new  countdown  number  on  title  screen  */ 
pushmatrix(); 

ortho2(0.0,  1023.0,  0.0,  767.0); 
viewport  (0,1023,0, 767); 

sprintf(temp,  "Countdown  to  launch;  %d%",  98  -  col); 
color(BLUE); 

rectf(780.0,  15.0,  1010.0,  30.0); 
color(CYAN); 

cmov'2i(788.  20); 
narsirt  tempi; 
pop  matrix  I ); 

for  (row  =  0;  row  <  99;  ++row)  { 

/*  choose  which  color  ramp  to  use  so  that  a  checker  board 
effect  is  acheived  * / 
if  ((row+col)%2){ 

colormin  =  256; 
colormax  =  461; 


} 

else  { 

colormin  =  462; 
colormax  =  667; 


*  build  the  polygon  ‘ 

trianglel|0)j2!  =  (float)row  *  (-41.01)  *  8.0; 

triangleljoj(oj  =  (float)col  *  41.01  *  8.0; 

trianglel[0]jl)  =  pow((float)(gridpixel[row][colj4'elev_mask) 

,  ALTSCALE); 

triang]el[l)(2)  =  (float)row  *  (-41.01)  *  8.0; 

trianglel;lj[0]  =  (float)  (col-t-1)  *  41.01  *  8.0; 

trianglel(l][l]  =  pow((fioat)(gridpixel[rowj[col+l)ilielev  mask) 

,  ALTSCALE); 

trianglelj2](2j  =  (float)(row  +  l)  *  (-41.01)  *  8.0; 
triangleli2i0  —  (floac)col  *  41.01  '  8.0: 

triangiel[2|(l|  =  pow((float)(gridpixel(row+lj(colj&elev^mask) 

.ALTSCALE); 

copy  common  vertex  values  for  opposing  triangle  of  grid  *  . 
for  (vertex  =  1;  vertex  <  3;  — -vertex)  { 

triangle2[vertexi(0l  =  triangleiivertexi|0l; 
tnangle2(vertexj[r  =  triangleljvertex;[l|; 
triangle2jvertex](2j  =  trianglel  [vertexj[2|; 

} 

/*  change  corner  coordinate  to  form  opposing  triangle  of  grid  */ 
triangle2[0][2]  =  ( float )( row  +  1)  *  (-41.01)  *  8.0; 
triangle2[0](0|  =  (float)(col+l)  *  41.01  *  8.0; 

triangle2[0j[lj  —  pow((float)(gridpixel[row+ l)[co)+ lj&elev  mask) 

,  ALTSCALE)  ; 

/*  compute  an  interior  point  for  trianglel  */ 
ax  =  trianglel[0|(0]  +  15.0; 
ay  =  -10.0; 

a z  =  trianglel[0]j2]  -15.0; 

/*  light  and  orient  trianglel  */ 

Iightonentl  triangle  1. 3. ax.  ay,  az.lx.ly.iz.  colormin.  colormax.  .t color  1 1 

ompute  interior  point  for  tnanglei 
ax  =  tnangle2|0|(G|  -  15.0; 
ay  =  -10.0; 

az  =  triangle2(0||2|  +15.0; 

/*  compute  the  light  for  and  orient  triangle2  */ 
lightorient(triangle2, 3, ax,ay,az, lx, ly,lz, colormin, colormax,  &color2); 

/*  compute  average  color  for  the  square  *  j 
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COLORRAMP 


/*  constructs  the  color  ramps  to  be  used  for  displaying  the  terrain. 

If  greyscale  is  true,  constructs  greyscale  ramps,  else  it 
constructs  green  ramps.  */ 

finclude  "fogm.h"  ,  *  fogm  constants  */ 

colorramp(greyscale,init) 
int  greyscale,  init; 

{ 

int  i; 

j*  build  two  gamma  corrected  color  ramps  with  slightly  offset  colors  */ 
if  (greyscale)  { 

gammaramp(1.5,256,205,255,255,255,50,50,50);  /*  even  terrain  ramp  */ 
gammaramp)  1.5.462,205.245,245,245.40.40,40);  *  odd  terrain  ramp  */ 

gammaramp(1.5,668,180,235,2S5,235,30,30,30);  /*  tank  ramp  */ 
mapcolor(SKYBLUG,230,230,230);  /*  sky  color  */ 

mapcolor(ROADGREY,35,35,35); 

} 

else  { 

gammaramp!  1.5,256,205,0,255.0,0,50.0);  /*  even  terrain  ramp  * 

gammaramp(l. 5, 462, 205,0, 245, 0.0,40,0);  ,  *  odd  terrain  ramp  *, 

gammaramp(1.5,668,180,255,165,55,75,55,0);  /*  tank  ramp  */ 

mapcolor(SKYBLUE,200,200,255);  j*  sky  color  * ) 

mapcolor(ROADGREY,35,35,35); 


if  (init)  { 

mapcolor(  16,0,70,0);  /*  set  up  colors  for  contour  map  */ 

mapcolorj  17,0,80,0); 

mapcolor(  18,0,90,0); 

mapcolor(  19,0, 100,0) ; 

mapcolor(20,0, 110,0); 

mapcolor(21, 0,120,0); 

mapcolor(22, 0,130,0); 

mapcolorj  23, 0,140,0); 

mapcolor(24,0,150,0); 

maDcolor!  25.0. 165.01; 

mapcoiorl  26.0. 180.0 ); 

mapcolor(  27. 0.190,0): 

mapcolor(28, 0,2 10,0); 

mapcolor(29, 0,225,0); 

mapcolor  jsO, 0,240,0) ; 

mapcolorjs  1,0, 255,0); 

mapcolor(32,75,55,0); 

mapcolor(33,95,60,0); 

mapcolor|34, 115, 70,0); 

mapcolorj35, 125, 76,0); 


mapcolor( 36, 135,83,0); 

mapcolor(37, 145,90,0); 

mapcolor(38, 155.97,0); 

mapcolor(39, 165, 105 ,0) ; 

mapcolor(40, 175, 110,0); 

mapcolor(41, 185, 1 13,0); 

mapcolor(42, 190,118,0); 

mapcolor(43, 200, 127,0); 

mapcolor(44,210,135,30); 

mapcolor(45, 225, 145,35); 

mapcolor(46,240, 155,45); 

mapcolor(47,255,165,55); 

for  (i=64;  i<128;  i++)  mapcolor(i,0,0,255); 

for  (i=128;  i<256;  i-r+)  mapcolor(i,255,0,0); 

mapcolor(851,0,150,0);  /*  set  up  colors  for  instruction  box  */ 

mapcolor(852, 255, 165,55); 

mapcolor(853,95.60.0); 

mapcolor(854. 0,0,0);  /*  color  for  indicator  box  background*/ 

} 

} 


COMPASS 


/*  compute  the  compass  heading  in  degrees  of  the  input  direction.  */ 

#include  "fogm.h"  /*  fogm  constants  * f 

float  compass(direction) 
double  direction; 

{ 

float  compassdir; 

compassdir  =  RTOD  *  direction; 
if  (compassdir  <=  90.0) 

compassdir  =  90.0  -  compassdir; 

else 

compassdir  =  450.0  -  compassdir; 
ret  urn  (compassdir  ); 

} 
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DISPLAY  TERRAIN 


/*  Compute  which  polygons  need  to  be  drawn  to  display  the  terrain  and 
output  them  in  an  order  such  that  the  polygons  farthest  from  the  viewer 
are  drawn  first  and  those  closest  are  drawn  last. 

Note:  Eventhough  this  seems  like  a  long  routine,  it  is  broken  into  8 
independent  cases  based  on  the  direction  the  camera  is  looking. 

If  you  understand  one  case  the  others  are  merely  mirror  images  of  the 
algorighm  for  other  octants.  */ 

finclude  "fogm.h" 
finclude  "math.h" 
finclude  "gl.h" 

display_terrain(vx,  vy,  vz,  px,  py,  pz,  fovy, 
firstxgrid,  firstzgrid,  lastxgrid,  lastzgrid) 

Coord  vx,  vy,  vz,  px,  py,  pz; 
int  fovy; 

short  firstxgrid,  firstzgrid,  lastxgrid,  lastzgrid; 


extern  float  ground  planei4j(3|; 
extern  long  gndplanecolor; 
extern  Object  road(99'[99|; 
extern  Object  targetj 99](99); 
extern  float  savetriangle(99] {99j [2] [3] [3] ; 
extern  long  gridcolor[99j|99j; 

double  lookdir; 

int  threshold,  count,  startx,  startz; 
short  xgrid,  zgrid; 
float  tanval; 
float  y; 

if  (TV)  viewport(0, 474, 0,474); 
else  viewport(0, 767,0, 787); 
pushmatrix(); 

•olorlSKYBLUE); 

’learf); 

ortho2(0. 0,1023.0,0.0,767.0);  '*  outline  the  screen  */ 

color(BLACK); 

recti(0, 0,1023,767); 

popmatrix(); 

pushmatrix(); 

perspective(fovy,  1.0, 0.0, 19500.0); 
Iookat(vx,vy,vz,px,py,pz,0.0); 


/*  determine  the  direction  of  the  line  of  sight  */ 

lookdir  =  (double)atan2((float)(vz  -  pz),  (float)(-(vx  -  px ) ) ) ; 

if  (lookdir  <  0.0)  lookdir  +=  TWOPI; 

/*  lay  down  the  ground  plane  */ 
color(gnd  plane  color); 
polf(4,  ground _plane);  ■ 

/*  put  the  grid  objects  through  the  geometry  engine  in  an  order 
based  on  the  lookdir.  */ 
if  (lookdir  >  SEVENQTRPI) 

{ 

/*  8th  OCTANT  V 

threshold  =  (int)(tan(lookdir-rHALFPI)  +  0.5); 

count  =  0; 
startx  =  lastxgrid; 
startz  =  firstzgrid; 
while  (startz  <=  lastzgrid)  ( 
zgrid  =  startz; 
xgrid  =  startx; 

while  ((xgrid  <=  lastxgrid)  &&  (zgrid  <=  lastzgrid))  { 

color(  gridcolor!  zgrid  |  i  xgrid  I ) ; 
polf(3,&savetriangleizgrid|  [xgrid  J[0j  j0|[0j); 
po  lf(3,4zsavetriangle(zgrid|  [xgrid  jjljjo]  jo] ); 

if  (road [zgrid ] [xgrid]  !=  0)  callobj(road[zgrid](xgrid]); 
if  ( target [ xgrid ] [ zgrid |  !=  0)  callobj(target|xgrid]]zgrid]); 

/*  check  if  tank  should  be  drawn  now  */ 

zgrid  +=  1; 
count  +=  1; 

if  (count  >=  threshold)  { 
xgrid  +=  1; 
count  =  0; 

} 

} 

startx  -=  (: 

:ount  =  0: 

if  (startx  <  firstxgrid)  { 
startx  =  firstxgrid; 
startz  +=  threshold; 

} 

} 

} 

else  if  ((lookdir  >  THREE  HALVES  PI)  ick  (lookdir  <=  SEVEN  QTR  PI)) 
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lm  7th  OCTANT  */ 

tanval  =  tan(lookdir-t-HALFPl); 

if  (tanval  ==  0.0) 

threshold  =  1000; 

else 

threshold  =  (int)((1.0/tanval)  +  0.5); 

count  =  0; 
startx  =  lastxgrid; 
starts  =  firstzgrid; 
while  (startx  >=  firstxgrid)  { 
zgrid  -  startz; 
xgrid  =  startx; 

while  ((xgrid  >=  firstxgrid)  iiti  (zgrid  >=  firstzgrid))  { 

color(  gridcolorj  zgrid  j  ( xgrid  ] ) ; 
polf(3,&savetrianglejzgrid|[xgridj|0j[0j[0j); 
polf(3,&savetnangleizgridi:xgrid!  1  0i|0<); 
if  (roadjzgridjjxgndj  !=  0)  caJiobj(road[zgndj|xgridj); 
if  (target|xgrid|[zgridj  !=  0)  callobj(target[xgrid][zgrid|); 

xgrid  -=  1: 
count  -  =  1; 

if  (count  >=  threshold)  { 

sgrid  -=  1; 
count  =  0; 

} 

} 

startz  +=  1; 
count  =  0; 

if  (startz  >  lastzgrid)  { 
startz  =  lastzgrid; 
startx  -=  threshold; 

} 

} 

} 

else  if  ((lookdir  >  FIVE  QTR  PI)  kk  (lookdir  <=  THREE  HALVES  PI)) 

{ 

*  *)th  OCTANT  ■ 

’anval  -  -tanUookdir— HALFPI); 
if  (tanval  ■==  0.0) 

threshold  =  1000; 

else 

threshold  =  (int)((1.0/tanval)  +  0.5); 

count  =  0; 
startx  =  firstxgrid; 
startz  =  firstzgrid; 
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while  (startx  <=  lastxgrid)  { 
zgrid  =  startz; 
xgrid  =  startx; 

while  ((xgrid  <=  lastxgrid)  kk  (zgrid  >=  firstzgrid))  { 

coior(gndcoior|Zgrid|[xgrid!); 

po  lf(3, izsavetrianglejzgrid]  [xgrid  J[0i[0][0|); 

polf(3,icsavetriangle[zgrid]  [xgrid  j  j  1  j  [Oj  [0] ) ; 

if  (roadjzgridj [xgrid]  !=  0)  callobj(road[»grid)[xgrid]); 
if  (targetlxgridjjzgridj  !=  0)  callobjftargetlxgridHzgrid1); 
xgrid  +  =  1; 
count  +  =  1; 

if  (count  >=  threshold)  { 
zgrid  -=  1; 
count  =  0; 

} 

startz  +=  1; 

count  =  0; 

if  (startz  >  lastzgrid)  ( 
startz  =  lastzgrid; 
startx  +=  threshold; 

} 

} 

} 

else  if  ((lookdir  >  PI)  kb  (lookdir  <=  FIVE  QTR  PI)) 

{ 

/*  5th  OCTANT  */ 

threshold  =  (int)(-tan(lookdir+HALFPI)  +  0.5); 


count  =  0; 
startx  =  firstxgrid; 
startz  =  firstzgrid; 
while  (startz  <=  lastzgrid)  { 
zgrid  =  startz; 
xgrid  =  startx; 

while  (xgrid  •=  hrstxgrul)  (zgrid  •  =  lastzgrid))  { 

■oiorl gndcolor  zgridl  xgrid i); 

polf(3,4csavetriangle[zgrid|[xgridj[0)[0j[0|); 
polf(3,3£savetrianglejzgridj  (xgrid  j[l][0)[0j); 

if  (road[zgrid][xgrid)  !=  0)  callobj(road[zgrid]|xgrid[); 
if  (target [xgrid [[zgrid |  !=  0)  cailobj(target)xgridj[zgrid]); 
zgrid  +  =  1; 


if  (count  >=  threshold)  { 
xgrid  -=  1; 
count  =  0; 

} 

} 

startx  —  —  l; 
count  =  0; 

if  (startx  >  last  xgrid)  { 
startx  =  lastxgrid; 
starts  +=  threshold; 

} 

} 

} 

ebe  if  ((lookdir  >  THREE  QTR  PI)  kk  (lookdir  <=  PI)) 

{ 

/*  4th  OCTANT  7 

threshold  =  (int)(tan(lookdir— HALFPI)  -  0.5); 

count  =  0; 
startx  =  firstxgrid; 
startz  =  lastzgrid; 
while  (startz  ,■>  =  firstzgnd)  { 
zgrid  =  startz; 
xgrid  =  startx; 

while  ((xgrid  >=  firstxgrid)  kk  (zgrid  >=  firstzgrid))  { 

color(gridcolor(zgrid]  [xgrid]); 
polf(3,&savetrianglejzgrid][xgrid][0][0][0]  ; 
polf  ( 3  .itsavetrianglejzgrid]  [xgrid]  [  1]  [0|  [0] ) ; 
if  (road[zgrid][xgrid]  !=  0)  callobj(road[zgrid]  [xgrid]); 
if  (targetfxgrid] [zgrid]  !=  0)  calIobj(t<irget[xgrid][zgridJ); 

zgrid  -=  1; 
count  +=  1; 

if  (count  >=  threshold)  { 
xgrid  -=  1; 
count  =  0; 

} 

i 

r 

startx  +=  J ; 
count  =  0; 

if  (startx  >  lastxgrid)  { 
startx  =  lastxgrid; 
startz  -=  threshold; 

} 

} 
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else  if  ((lookdir  >  HALFPI)  kk  (lookdir  <=  THREE  QTR  PI)) 

{ 

/*  3rd  OCTANT  */ 

tanval  =  tan(lookdir+HALFPI); 

if  (tanval  =  =  0.0) 

threshold  -  1000; 

else 

threshold  =  (int)((1.0/tanval)  +  0.5); 


count  =  0; 
startx  =  firstxgrid; 
starts  =  lastzgrid; 
while  (startx  <=  l&stxgrid)  { 
zgrid  =  startz; 
xgrid  =  startx; 


while  ((xgrid  <=  lastxgrid)  kk  (zgrid  <=  lastzgrid))  { 


color(  gridcolor[zgrid  |  [xgrid  j ) ; 
polf(3,<£savetriangle[zgrid)[xgrid][0][0][0]); 
polf(S,&savetriangle[zgrid] [xgrid  j(l](0)[oj); 


if  (roadizgrid[[xgridj  !=  0)  cailobj(roadlzgndi|Xgnd|); 


if  (target ;  xgrid  |  j  zgrid  I  !=  0)  cailobj(target|xgnd|!zgrid!); 


xgrid  i l: 
count  +=  1; 


if  (count  >=  threshold)  { 
zgrid  +=  1; 
count  =  0; 

} 


startz  -=  1; 
count  =  0; 


if  (startz  <  firstzgrid)  { 
startz  =  firstzgrid; 
startx  +=  threshold; 

} 


else  if  ((lookdir  --  QTR  PI)  kk  (lookdir  <-  HALFPI)) 


/*  2nd  OCTANT  */ 

tanval  =  -(tan(lookdir-t-HALFPI)); 

if  (tanval  ==  0.0) 

threshold  =  1000; 

else 

threshold  =  (int)((1.0/tanval)  +  0.5); 


count  =  0; 
startx  =  lastxgrid; 
startz  =  lastzgrid: 
while  {startx  >=  firstxgrid)  { 
zgrid  =  startz; 
xgrid  =  startx; 

while  ((zgrid  <=  lastzgrid)  kk  (xgrid  >=  firstxgrid))  { 

color(  gridcolor  [z  grid  j  [  xgrid  ] ) ; 
polf(3,iisavetrianglejzgrid][xgrid][0][0][0]); 
polf(3,<J:savetriangle[zgrid|  [xgrid  j[li[oj(0]); 

if  (road[zgrid|[xgrid]  !=  0)  callobj(road[zgridj[xgrid]); 
if  (target[xgridj[zgrid]  !=  0)  callobj(targetlxgridjjzgridj); 
xgrid  -=  1; 
count  +=  1; 

if  (count  >—  threshold)  { 
zgrid  +=1; 
count  =  0; 

} 

} 

start*  -=  1; 
count  =  0; 

if  (startz  <  firstzgrid)  { 
startz  =  firstzgrid; 
startx  -=  threshold; 

} 

} 

} 

else  if  ((lookdir  >=  0.0)  kk  (lookdir  <=  QTR  P1)) 

{ 

/*  1st  OCTANT  */ 

threshold  =  (int)(-tan(lookdir+HALFPI)  +  0.5); 

count  =  0; 
startx  =  lastxgrid; 
startz  =  lastzgrid; 

while  (startz  >=  firstzgrid)  { 
zgrid  =  startz: 
xgrid  =  startx: 


while  ((xgrid  <=  lastxgrid)  kk  (zgrid  >=  firstzgrid))  { 


color(gridcolorjzgrid)  [xgrid]); 

polf(3,&savetriangle[zgrid]jxgrid|[0][0][0]); 

polf(3,&savetriangle[zgrid|[xgrid][lj(0][0]); 


if  (road[zgrid|(xgrid|  !=  0)  callobj(roadjzgrid][xgridj); 
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if  (target[xgrid|[zgridj  !=  0)  callobj(target|xgrid][zgrid]); 
zgrid  -=  1; 
count  -•-=  1; 

if  (count  >=  threshold)  { 
xgrid  +=  l; 
count  =  0; 

} 

} 

st art x  -=  1; 

count  =  0; 

if  (startx  <  firstxgrid)  { 
st  art  x  =  firstxgrid; 
st&rtz  -=  threshold; 

} 

} 

} 

popmatrix(); 


DIST  TO  LOS 


#include  "gl.h" 

#include  "math.h" 

float  dist  to  _los(vx,vy. vz.px.py.pz, point) 

'  *  compute  che  distance  from  the  point  "point”  to  the  line  of  sight 

Coord  vx,vy,vz,px,py,pz; 
float  point(3|; 

{ 

float  a,b,c;  /*  direction  numbers  of  line  of  sight  */ 
float  d,e,f; 
float  dist; 

a  =  (float)(px  -  vx); 
b  =  ( float )(py  -  vy); 

c  =  (float)(pz  -  vz); 

d  =  pointjOj  -  (float)vx; 
e  =  point [  1  ]  -  (float)vy; 
f  =  poinc;2!  -  (floac)vz: 

disc  =  sqrt((up_i(e*c  -  f*b,2)  •+•  up_i(Pa-  d*c,2j  —  up_i(d*b 
(up_i(a,2)  -  up_i(b,2)  +  upj(c,2))): 


return(dist); 


DO  BOUNDARY 


#include  "gl.h" 

#include  "math.h" 
Jtinclude  "stdio.h" 
f  include  "fogm.h" 

#define  X  0 
#define  Y  1 
^define Z  2 

#define  DIAGONAL  0 
#define  HORIZONTAL  1 
#define  VERTICAL  2 

#define  LOWER  0 
#define  UPPER  1 

#define  NONE  0 
#define  INTERSECT  1 
#define  PROPER  2 


do  boundarv(bound_tvpe.  which  triangle,  xgnd.  zgrid, 
boundstart,  bound_end,  left  start, 
left  end,  right  start,  right  end,  start  corner  flag, 
end  corner  flag,  polyl,  vertexcnt) 

int  bound  type,  which  triangle,  xgrid,  zgrid; 

float  bound_start[3],  bound_end[3],  left _start[ 3] ,  left  end|3], 
right_start[3],  right_end[3|; 

int  ‘startcornerflag,  *end_corner_flag; 

float  poly  1  [  10]  [3] ; 

int  ‘vertex  cnt; 


{ 

int  test  ,ndex.  nt.  index: 

float  bound_right(3|,  bound_left[3|,  bound_start  edge  (3|, 
bound  end _edge[3]; 

float  vertex  array [  10]  [3! ; 
float  road_poly[10|j3j; 
float  grid _poly [  10) [3 j ; 

int  intersect  cnt; 
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int  intersecttype,  decending  sort; 
float  upperbound,  lowerbound; 


float  gnd_level(); 
int  in_this_poly(); 
intersect  cnt  =  -1; 

/*  compute  the  verticies  of  the  road  segment  currently 
being  worked  on  */ 
for  (index  =  0;  index  <  3;  -r-r  index)  { 

road  poly[0](index]  =  left  startjindexj; 
road_poIy[l](index|  =  leftendfindexj; 
road  poly (2 1 [index]  =  right  end[index|; 
road_poly|3|[index|  =  rightstartjindexj; 

} 

/*  compute  the  verticies  of  the  grid  triangle  associated  with 
this  boundary  * / 

grid  _poly|0l|X!  =  ( float )(xgrid* FT  LOOM); 
grid  polyiOl  Zi  =  ( float )((zgrid—  1)*FT_100M); 
grid  poly ( 1 ; [ X [  =  (float  )((xgrid-+- 1)*FT  100M); 
grid_p'tly[lj,Zi  =  (float)(zgrid*FT_100M); 
if  (which  triangle  ==  UPPER)  { 

grid _ poly[2][X]  =  (float)((xgrid+l)*FT_100M); 

grid  poly[2]]Z]  =  (float)((zgrid+l)*FT_100M); 

} 

else  { 

grid_poly  [2]  [X]  =  (float)(xgrid*FT_100M); 
grid  poly [2] [Z]  =  (float)(zgrid*FT_100M); 

} 

if  (bound_type  ==  HORIZONTAL)  { 
test  index  =  X; 

} 

else  if  (boundtype  ==  VERTICAL)  { 
test  index  =  Z; 

} 

else  if  (bound  type  ==  DIAGONAL)  { 

test  jndex  =  Z: 

K 

l 

if  (bound  start[test  index|  <  bound_end(test_indexj)  { 
lower _bound  =  bound  start] test_indexj; 
upper  bound  =  bound  end[test  index); 

} 

else  { 

lower  bound  =  bound  end[test  index]; 
upper_bound  =  bound  start[test_index]; 

} 
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I*  determine  points  of  intersection  between  left  and  right  sides 
of  the  road  and  the  boundary  */ 

line_intersect2(bound_start,  bound_end,  right_start,  right  end, 
boundjright,  &intersect_type); 
if  (intersect_type  — =  PROPER)  { 

/*  intersection  lies  on  road  line  segment,  add  intersection 
to  array  */ 
intersectcnt  +=  1; 

vertex_array(intersect_cnt|[X)  =  bound_right[Xj; 
vertex_array[intersect_cntj[Zj  =  bound  right.Zj; 
vertex_array[intersect_cntj[Y]  =  gnd_level(bound_right[X], 
•boundright(Zj); 

} 

else  if  ((intersecttype  ==  INTERSECT)  kk 
(in_this_poly(grid_poly,  3,  rightstart))  kk 
(bound  right! test  index!  >  lowerbound)  kb 

(bound  right  test  index.  <  upper  bound))  ( 

/*  intersection  point  is  beyond  the  bound  of  the  road’s  right 

line  segment,  but  the  right  start  point  is  inside  the  polygon  so 

add  the  road’s  right  start  point  to  the  vertex  .array  * 

intersect  _ent  —  =  1; 

vertex_array|intersect_cntjjXj  =  rightstar^Xjj 
vertex_array[intersect_cnt||Z|  =  right_start[Z]; 
vertex _array [ in tersec t _c n 1 1 [ Y]  =  gnd  Ievel(right  start [Xj, 
-right_start(Z]); 

} 

else  if  ((intersect  type  ==  INTERSECT)  kk 
(in  this  polyjgrid  poly,  3,  rightend))  kk 
(bound_right[test_indexj  >  lower  bound)  kk 
(bound  rightjtest  index]  <  upper  bound))  ( 

/*  intersection  point  is  beyond  the  bound  of  the  road’s  right 

line  segment,  but  the  right  end  point  is  inside  the  polygon  so 
add  the  road’s  right  end  point  to  the  vertex  array  */ 

intersect  cnt  -t-=  1; 

vertex  array  (intersect  cntllXI  =  right  end!XI; 

vertex  array  intersect  cnt.  Z!  -  right  *nd  Z 

vertex  array i intersect  _<-nt  Y  =  gnd  'eveilnght  -ndiX. 

-right  -ml  Z  ); 

} 

line_intersect2(bound_start,  boundend,  left  start,  left  end, 
bound  left,  Atintersecttype); 
if  (intersect  type  ==  PROPER)  { 

/*  intersection  lies  on  road  line  segment,  add  intersection 
to  array  */ 
intersect  cnt  +=  1; 

vertex_array[intersect_cnt][X]  =  bound  leftjX]; 
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vertex  array[intersect_cntj[Z|  =  bound_left(Z); 
vertex_arrayjintersect_cnt](Y]  =  gnd_level(bound  _left(X], 

•bound  left(Z|); 

} 

else  if  ((intersect  type  ==  INTERSECT)  kk 
(in  this_poly(grid  poly,  3,  leftstart))  kk 
( bound  _lefti  test  _indexi  >  lower_bound)  kk 
(bound_left(test_indexj  <  upper_bound))  { 

/*  intersection  point  is  beyond  the  bound  of  the  road’s  left 

line  segment,  but  the  left  start  point  is  inside  the  polygon  so 
add  the  road’s  left  start  point  to  the  vertex  array  */ 

intersect_cnt  +=  1; 

vertex_array[intersect_cnt](Xj  =  left_start[X]; 
vertex  array(intersect_cnt][Z]  =  left  start[Z]; 
vertex  array  [intersect  cnt|(Yj  =  gnd_level(left_start[Xj, 
-leftstartjZJ); 

} 

else  if  ((intersect_type  ==  INTERSECT)  kk 
(in_this_poly(grid_poly,  3,  left_end))  kk 
(bound_left[test_index]  >  lower  bound)  kk 
(bound  left[test  index)  <  upper_bound))  ( 

/  *  intersection  point  is  beyond  the  bound  of  the  road’s  left 

line  segment,  but  the  left  end  point  is  inside  the  polygon  so 
add  the  road’s  left  end  point  to  the  vertex  array  */ 

intersect  _cnt  +=  1; 
vertex_array[intersect_cnt][X] 
vertex  array  [  in  tersec  t  cn  t  j  [  Z j 
vertexarray  [intersect  _cnt][Y| 

-left  end  [Z]); 

} 

/*  if  either  of  the  bound’s  end  points  fall  within  the  bounds  of  the 
road,  add  them  to  the  array*/ 

if  ((!*start_corner_flag)  kk  (in_this_poly(road_poly,  4,  bound  start)))  { 
/*  put  in  start  bound  point  */ 

‘start  corner  flag  =  TRUE; 
intersect_cnt  +=  1; 

vertex  irray  intersect  cnt  X  =  bound  start  Xi; 

vertex  arravi intersect  'nt  Z  -  bound  itarti Zb 

vertex  irray. intersect  nr  Y  =  bound  start  Y!; 

)  "  ‘ 

if  ((!*end_corner  flag)  kk  (in_this_poly(road_poly,  4,  bound  end)))  { 

/*  put  in  end  bound  point  */ 

*end_corner_flag  =  TRUE; 
intersectcnt  +=  1; 

vertex  array  [intersect  cnt  ]  [  X)  =  bound_end[X]; 
vertex  arrayjintersect  cntj [Z|  =  bound  end[Z|; 
vertex_array[intersect_cnt][Y|  =  bound_end[Y|; 


=  left_end[X); 

=  leftendjZJ; 

=  gnd_level(left_end[X], 
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} 

/*  determine  the  point  of  intersection  between  the  start  and  end 
bound  of  the  road  and  the  grid  boundary  */ 
line_interaect2(bound_start,  bound_end,  left  start,  right  start, 
bound  start_edge,  ^intersect  type); 
if  (intersect  _type  ==  PROPER)  f 

/*  intersection  lies  on  road  line  segment,  add  intersection 
to  array  */ 
intersect  _cnt  +=  1; 

vertex_array[intersect_cntj[Xj  =  bound_start_edge[X]; 
vertex_array[intersect_cntj(Z|  =  bound  _st  art  _edge(Z]; 
vertex_array[intersect_cnt|[Yj  =  gnd_level(bound_start_edgeiXl, 
-boundstart  _edge(Z|); 

} 

line_intersect2(bound_start,  bound  end,  leftend,  right_end, 
bound  end  edge,  &intersect_type); 
if  (intersect  type  ==  PROPER)  { 

/*  intersection  lies  on  road  line  segment,  add  intersection 
to  array  *  / 
intersect  cnt  +=  1; 

vertex_array[intersect_cnt](Xj  =  bound_end_edge[Xj; 
vertex_array(intersect_cntl[Z)  =  bound  end  edgejZl; 
vertex_aiTay(intersect_cnti(Y'  -=  gnd  levelfbound  end  edgeiX’, 
-bound  end  edgejZI); 

} 

/*  put  the  points  from  the  vertexarray  into  the  polyl  array  in 
the  proper  order  */ 

decendingsort  =  (bound_start[test_indexj  !=  lower  bound); 
sort_array(vertex_array,  intersect  cnt,  decending  sort,  test  index); 

for  (cnt  =  0;  cnt  <=  intersect  cnt;  ++cnt)  { 

“vertexcnt  +=  1; 

polyl[*vertex_cnt][X)  =  vertex_array[cntJ(Xj; 
polyl[*vertex_cnt][Y|  =  vertex_array[cntj[Y); 
polyl(*vertex_cntj[Z)  =  -vertex_array[cntj(Z]; 

} 

} 


EDIT  INDBOX 


/*  update  the  control  settings  of  the  indicator  box  */ 

^include  "fogm.h" 

#include  "gl.h" 

edit_indbox(indbox,  speedtag,  headingtag,  elevtag,  altmsltag, 
xoomtag,  tilttag,  pantag,  desigtag,  speed,  compassdir, 
vx,  vy,  vx,  pan,  tilt,  zoom,  designate) 

Object  indbox; 

Tag  speedtag,  headingtag,  elevtag,  altmsltag,  zoomtag,  tilttag,  pantag, 
desigtag; 

float  speed,  compassdir; 

Coord  vx,  vy,  vz; 

double  pan,  tilt; 

inc  designate; 

inc  zoom; 

{ 

char  chspeed[5],  chheading[5],  chelev[5],  chaltmslj5]; 

float  gnd_level();  i 

float  zoomtic,  pantic,  tilttic;  | 

sprintf(chspeed,"%4.0f", speed);  /*  convert  speed  to  string  */ 

sprintf(chheading,"%3.0f', compassdir);  /*  convert  heading  to  str  * / 

sprintf(chelev,"%4.0f',vy  -  gnd_level(vx,vz));  /*  convert  elev  AGL  to  str  */  J 

sprintf(chaltmsl,"%4.0f,,vy);  /*  convert  alt  MSL  to  str  */  j 

/*  compute  new  location  for  zoom,  pan,  and  tilt  indicators  */ 

zoomtic  =  zoom  *  -0.2786  +  222.128; 
tilttic  =  tilt  *  721.92682  +  365.0; 
pantic  =  pan  *  -721.92682  +  435.0; 

editobj(indbox);  /*  update  the  indicator  display  */ 

objreplace(speedtag); 

rharstr(chspeed); 

objreplace(  headingtag); 

charstr(chheading); 

objreplace(elevtag);  j 

charstr(chelev);  .  | 

objreplace(  altmsltag);  \ 

charstr(chaltmsl);  1 

objreplace(zoomtag);  * 

move2(28.0, zoomtic); 
objreplace(tilttag); 
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move2(42.0,tilttic); 

objreplace(pantag); 

move2(pantic,27.0); 

objreplace(desigtag); 

cmov2i(deaignate  ?  10  :  19,10); 

charstr(designate  0  "DESIGNATE"  :  "REJECT"); 

closeobj(); 


vw 
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EDIT  NAVBOX 


#include  "fogm.h" 

^include  "math.h" 

#include  "gl.h" 

edit  navbox(navbox,  arrowtag,  vx,  vz,  direction.firstxgrid,  firstzgrid, 
lastxgrid,  lastzgrid) 

Object  navbox; 

Tag  arrowtag; 

Coord  vx,  vz; 
double  direction; 

short  firstxgrid,  firstzgrid,  lastxgrid,  lastzgrid; 

{ 

Coord  arrowx,  arrowy,  larrowx,  1  arrowy ,  rarrowx,  r arrowy; 

/*  compute  coordinates  of  arrow  line  segments  for  nav  control  box  */ 

arrowx  =  vx  t  cos(direction)  *  2.0  *  FEETPERGRID; 

arrowy  =  vz  -  sin(direction)  *  2.0  *  FEETPERGRID; 

larrowx  =  arrowx  +  cos(direction  -  2.3561945}  *  FEETPERGRID; 

larrowy  =  arrowy  -  sin(direction  -  2.3561945)  *  FEETPERGRID; 

rarrowx  =  arrowx  -r  cos(direction  4-  2.3561954)  *  FEETPERGRID; 

rarrowy  —  arrowy  -  sin(direction  —  2.3561945)  *  FEETPERGRID; 

/*  update  the  contour  map  display  with  new  info  */ 

editobj  (navbox); 

objreplace(  arrowtag); 

move2(vx,vz); 

draw 2 ( arrowx,  arrowy); 

draw2(larrowx,  larrowy); 

move2(arrowx,  arrowy); 

draw2(rarrowx,  rarrowy); 

rect  ( firstxgrid*  FT  _100M,-firstzgrid  *  FT100M, 

(lastxgrid  +  1)*FT_100M,  (-lastzgrid-  1)*FT_100M); 
closeobj(); 


WWW 
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EXPLOSION 


^include  "gl.h" 
explosion  () 


int  i  j; 

pushviewport(); 
viewport(0, 1023, 0,767); 
color(BLACK); 
clear(); 
swapbuffers(); 
color(RED); 
clear!); 
swapbuffers(); 
swapbuffers(); 
color(  YELLOW); 
clew(); 
swapbuffers(); 
swapbuffersi); 
color(RED); 
clear) ); 
swapbuffers(); 
swapbuffers(); 
color(  YELLOW); 
clear(); 
swapbuffersQ; 
swapbuffers(); 
color(RED); 
clear(); 
swapbuffers(); 
swapbuffers(); 
for  (i  =  0;  i  <  100000;  i++) 
for  0  =  0;  j  <  10;  j++); 
popviewport(); 


FOGM  (MAIN) 


/*  fogm.c  —  an  IRIS-2400  program  by  Doug  Smith  k  Dale  Streyle 
It  reads  in  a  10km  x  10km  section  of  a  terrain  map,  computes  a  lighting 
and  shading  model  for  the  terrain,  and  allows  overflight  */ 


#include  "gl.h" 
#include  "device.h" 
^include  "fogm.h" 
^include  "math.h" 
^include  "get.h" 
^include  "stdio.h" 
#include  "sys/signal.h" 
^include  <sys/types.h> 
#include  <sys/times.h> 


/*  get  the  graphics  defs  */ 

/*  get  the  graphics  device  defs  */ 

/*  constants  */ 

/*  math  function  declarations  */ 
/*  monitor  type  include  file  */ 

/*  used  for  screen  dump  utility  */ 
/*  contains  the  time  sturcture  tms  * 
/*  for  time  calls  */ 


/ 


short  gridpixel[l00j[l00|;  /*  DMA  elevation  and  vegatation  data 
float  savetriangle!  99]  [99]  [21 [  Si  [3l ; 
long  gridcoIor[99J[99j; 

Object  road  [99]  [99]; 

Object  target[99][99); 


float  ground_planej4j[3'; 

long  gnd_plane  color; 

float  tgt_posiMAX_TGTSj(3j; 

short  tgt_grid_idx[MAX_TGTSj[2[; 

short  tgt_dir|MAX_TGTS|,  tgttotal  =  0; 

float  randx,  randy,  randz;  /*  random  offsets  from  tank  reference  point  * [ 
int  framecnt; 


float  min  elev,  maxelev; 
Coord  tankx, tanky,  tankz; 
float  frames_sec(l000][2[; 


main() 

{ 

int  greyscale  =  FALSE;  *  FALSE  —  color,  TRUE  =  greys  */ 

int  designate;  ;  *  boolean  indicating  desig/ reject  status  '/ 

int  flying  =  TRUE;  /*  boolean  controlling  flying  loop  */ 

int  active  =  TRUE;  /*  boolean  controlling  main  program  loop  */ 
int  nbyte,  socket,  connectclientQ;  /*  networking  variables  k  subroutine  */ 
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struct  tms  timestruct;  /*  structure  for  real-time  clock  calls  */ 

int  tgtidx;  /*  index  of  designated  target  */ 

double  direction;  [*  direction  of  travel  in  radians  */ 

float  speed;  /*  speed  of  travel  in  knots  */ 


float  compassdir;  /*  desired  direction  of  travel  in  compass  deg  */ 

int  fovy  =  550;  /*  field  of  view  in  perspective  command  */ 

double  pan  =  0.0, 

tilt  —  -15.0  *  DTOR;  /*  pan  and  tilt  angles  * / 

/*  contour  map,  indicator,  instruction  */ 

Object  contour,  navbox,  indbox,  instrbox; 

Object  tank,  pre_l_obj(7|; 

Tag  headingtag,  elevtag,  speedtag,  zoom  tag,  arrowtag,  tiittag,  pantag; 
Tag  desigtag,  altmsltag,  pre_l_tag(6]; 

Colorindex  unmask; 

Coord  vx,  vy,  vz;  /*  viewer  x  y  and  z  coordinates  */ 

Coord  px,  py,  pz;  /*  reference  x  y  z  coordinates  for  lookat  */ 

Coord  tgtx,  tgty,  tgtz;  /*  targeted  position  on  tank  */ 
float  randseedQ;  /*  random  number  generator  initialization  */ 
int  frames  =  -1; 

long  seconds,  lastseconds,  totalseconds  =  0; 
int  numpolys; 
float  elapsed; 
int  idx; 

FILE  *fopen(),  *fp; 

/*  first  and  last  x  and  z  indexes  of  the  grid  objects  to  draw  */ 
short  firstxgrid,  firstzgrid,  lastxgrid,  lastzgrid; 

readdatal);  *  read  the  data  tile  into  the  gridpixel  array  * 

/*  get  socket  number  for  networking  * / 

/*if  (NETWORKING)  socket  =  connect_client("npscs-irisl",3);  */ 

init_iris();  /*  initialize  the  iris  */ 

unmask  =  (l<<getplanes())  -  1; 
writemask  (unmask); 


randseed(times(&timestruct));  /*  seed  the  random  #  generator  */ 


init  tgtsQ; 


/*  define  targets  */ 


Screen  Dump(SCREENDUMP); 


/*  enable  screen  dumping  */ 


billboard(); 


/*  produce  intro  screen  */ 


colorramp(greyscale,TRUE);  /*  build  all  color  ramps  */ 

makescreens(pre_l_obj,  pre_l_tag);  /*  build  objects  for  prelaunch  */ 
makemap(idcontour);  /*  build  map  object  */ 

pre  1  obj[CONTOUR]  =  contour; 

prelaunch(&vx,  kvy,  &vz,  ^direction,  licompassdir, 

&  active,  pre  1  obj,  pre  1  tag); 


if  (active)  { 

maketank(&tank); 


/*  build  object  for  a  tank  */ 


build  road();  *  build  the  objects  that  comprise  the  roads  */ 

/*  process  terrain  data  to  build  polygons  and  compute  lighting  */ 
buildterrain(); 

/*  build  object  for  the  navigation  display  contour  map  */ 
drawnavbox(£cnavbox,  &arrowtag); 

/*  build  an  object  for  the  indicator  box  */ 

makeindbox(&indbox,&headingtag,«£elevtag,&:altmsltag,&speedtag, 

fczoomtag,Actilttag,&pantag,4cdesigtag); 


m akeinstrbox ( ic instrbox) ;  /*  build  object  for  control  instruction  box  */ 

}  /*  end  of  if  (active)  block  */ 

while  (active)  { 

framecnt  =  0; 

/*  initialize  the  operator  controls  (mouse  and  dials)  */ 
init_controls(&pan,  &tilt,  &fovy,  vy,  greyscale,  compassdir); 

pushviewport(); 
viewport  (0. 1 023.  (J.  767); 

color(SKYBLUE); 

clear(); 

popviewport(); 

callobj(instrbox); 

callobj(indbox); 

editobj(contour); 

objreplace(STARTTAG); 

viewport(768, 1023,512,767); 
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closeobjf); 

c&llobj  (contour); 

swapbuffers(); 

c&llobj  (instrbox) ; 

c&llobj  (contour); 

editobj(contour); 

objreplace(STARTTAG); 

viewport  (0,768, 0,768); 

closeobj(); 

flying  =  TRUE;  /*  missile  is  flying  */ 
designate  =  TRUE;  /*  a  target  can  be  designated  */ 

while(flying)  {  j*  until  tgt  is  hit  or  3-button  exit  */ 


/*  get  values  from  user  contols  (mouse  and  dials)  * / 
read  controls(<kdesignate,  <fcgreyscale,  &flying,  inactive, 

&speed,  ^direction,  &compassdir,  &vy, 

&pan,  &tilt,  &fovy); 

/*  calculate  which  target  was  closest  to  the  line  of 
sight  V 
if  (Idesignate)  { 

nearest  tgt (vx,vy,vz,px,py,pz,&tgt  idx); 

} 

/*  update  targets’  positions  */ 

get_tgt_posit(socket,  designate,  tgt  idx,  &tgtx,  &tgty,  &tgtz,  tank); 
/*  update  missile  position  */ 

update  missile  posit (indirect ion,  tcompassdir,  speed, 
designate,  tgtx,  tgty,  tgtz, 

&vx,  &vy,  &vz,  fcflying); 

/*  update  camera  lookat  position  */ 

update  look  posit(direction,  pan,  tilt,  vx,  vy,  vz, 

tgtx,  tgty,  tgtz,  designate,  fcpx,  Scpy,  &pz); 

I*  determine  which  polygons  need  to  be  drawn  * / 
view_bounds(vx,  vy,  vz,  px,  py,  pz,  tilt,  fovy, 

Attirstxgrid.  &.firstzgrid,  &lastxgrid.  &iastzgrid); 

*  edit  control  display  objects  to  reflect  new  values  * 
edit  navbox(navbox,  arrowtag,  vx,  vz,  direction,  flrstxgrid, 
firstzgrid,  lastxgrid,  lastzgrid); 

edit  indbox(indbox,  speedtag,  he&dingt&g,  elevtag,  altmsltag, 
zoomt&g,  tilttag,  p&nt&g,  desigtag,  speed, 
compassdir,  vx,  vy,  vz,  pan,  tilt,  fovy,  designate); 


/*  display  the  3-D  view  of  the  terrain  as  seen  by 


*  i/  \  C  •’  O  »'**•*  ‘  *  .  *  . 
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the  camera  */ 

display  ', errain(vx,  vy,  vz,  px,  py,  pz,  fovy, 
firstxgrid,  firstzgrid,  lastxgrid,  lastzgrid); 

/*  display  the  control  boxes  */ 
writemask(SAVEMAP); 
callobj(navbox); 
writemask(  unmask); 
callobj(indbox); 

swapbuffersQ; 

seconds  =  times(<£timestruct); 

numpolys  =  (lastxgrid  -  firstxgrid)*(lastzgrid-firstzgrid)*2; 
elapsed  -  (float) (seconds  -  lastseconds)/60.0; 
if  ((frames  >=  0)  &&  (frames  <  1000)  ){ 

frames_sec(frames][0|  =  (float)numpolys; 
frames_sec[frames)(lj  =  1.0/elapsed; 

} 

totaiseconds  -t-=  (seconds-lastsecondsj; 
if  (totaiseconds  >  7200)  { 

compactifyQ;  /*  do  garbage  collection  every  2  mins 
totaiseconds  =  0.0; 

) 

lastseconds  =  seconds; 
frames  +=  1; 

}  /*  end  of  flying  loop  */ 

if  (active)  {  /*  explode  &  restart  */ 

explosion(); 

prelaunch(&vx,  &vy,  Scv z,  ^direction,  &compassdir, 
active,  pre  l  obj,  pre  l  tag); 

} 

}  /*  end  of  active  loop  */ 

/*  write  out  performance  stats  */ 
fp  =  fopen("speed.data",  "w"); 
if  (frames  >  999)  frames  =  999; 
for  (idx  =  0;  idx  <=  frames;  ++idx)  { 

fprintf(fp.”0:o.2f  °o.2f0.  frames  sec; idx,  01,  frames  sec  idx i  I  ); 


} 


FILES.H 


/*  These  are  the  files  which  contain  data  for  the  terrain  elevations 
and  roads  *  / 

fdefine  TERRAIN _FILE  "/work ''terrain /tenkmsq.dat" 
fdefine  ROAD_FILE  "  work/ terrain,  Road. data" 

FOGM.H 

fdefine  elev_mask  OxlfiT  /*  mask  to  obtain  elev  value  from  datum  * 

fdefine  veg  mask  0x0007  /*  mask  to  obtain  vegatation  value  from 

shifted  datum  * 

fdefine  RD  0  /*  code  for  reading  a  file  in  "open"  */ 

fdefine  MAX  2800  /*  max  elev  (ft)  in  contour  map  */ 

idefine  MIN  967  ,  *  min  elev  ift)  in  contour  map  * 

fdefine  SKYBLUE  4095  /*  color  index  for  sky  color  * 

#define  ROADGREY  850  /*  color  index  for  the  road  * 

fdefine  DELTAFOVY  50  /*  field  of  view  (soom)  increment  of  5  deg  * 

fdefine  PI  3.1415927 

fdefine  TWOPI  6.2831853 

fdefine  HALFPI  1.5707963 

fdefine  THREE  HALVES  PI  4.7123889 

fdefine  QTR  PI  0.7853982 

•define  THREE  QTR  PI  2  3561945 

•define  FIVE  QTR  P!  3  9269908 

fdefine  SEVEN  QTR  PI  5.4977871 

fdefine  RTOD  57.29578  /*  radians  to  degrees  conversion  factor  * 

fdefine  DTOR  0.0174533  /*  degrees  to  radians  o  .  version  factor  * 

fdefine  FPS_TO_KTS  35.525148  /*  convert  feet  per  60th  seconds  to  knots  * 
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♦define  PANSENS  SO  0  *  scale  factors  (sensitivity)  for 

navigaion  controls  (mouse  and  dials) 


♦  define  SPEEDSENS  20 

♦define  TILTSENS  50  0 
♦define  D1RSENS  20  0 

♦define  MAXLOOKD1ST  32808.0  /*  maximum  distance  that  the  camera  can 

look  ahead  in  feet  */ 

♦define  FEETPERGRID  3280  8  '*  number  of  feet  in  1000  meters  * 

♦define  ALTSCALE  1  05  *  altitude  expansion  factor  altitudes  are 

raised  to  this  power  to  give  an 
exagerrated  effect  * 

*d»nne  M  \1\<,RIDS  1 1  j  *  numDer  it  'K  itrid  «]iur*!  in  he  Easi- 

West  direction 

♦define  Nl  MZGRILo  10  *  number  of  lk  grid  squares  in  the  North- 
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♦define 

CONTOUR 

0  *  Indicies  for  array  obj 

♦define 

SCREEN l 

1 

♦define 

SCREEN2 

2 

♦define 

SCREENS 

3 

♦define 

INSTR 

4 

♦define 

STATS 

5 

•  define 
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d 

♦define 

LAUNCH 

0 

/*  Indicie*  for  array  tag 

♦define 

TARGET 

1 

♦define 

DIR 

2 

♦define 

HEAD 

* 

-> 

♦define 

♦define 

TGT  4 

MISSILE 

5 

♦define  MAX  TGT  COLOR  847 
♦  define  MIN  TGT  COLOR  M8 


•  define  VI A  X  TGTS  100 


♦defin 
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GAMMARAMP 


/*  This  routine  puts  a  gamma-corrected  color  ramp  into  the  color  map. 
^include  <math.h> 

gammaramp(gammaconst. firstcolor, ncolors. 

brightred,brightgreen,brightblue, 

darkred,darkgreen,darkblue) 

float  gammaconst:  ,  *  Strength  of  Gamma  correction  (try  1.0)  */ 
long  firstcolor;  /  *  index  number  of  the  first  color  to  set  */ 
long  ncolors;  /*  the  number  of  colors  to  set  */ 

long  brightred.brightgreen.brightblue;  /*  the  bright  end  of  the  ramp  */ 
long  darkred,darkgreen,darkblue;  /*  the  dark  end  of  the  ramp  */ 

{ 

long  i;  *  temp  ioop  index  * 

float  scl.  *  scale  factor  for  gamma  correction  */ 

long  gcred. gcgreen.gcblue;  /*  gamma  corrected  colors  */ 

for(i=0,  i  <  ncolors;  !  +  -►)  /*  for  all  colors...*/ 

< 

/*  compute  the  scale  factor  */ 

scl  =  pow (( float )\i (float )( ncolors- 1)  ,  1.0/gammaconst); 

/*  compute  the  gamma  corrected  colors  */ 
gcred  -  scl  *  (bnghtred  -  darkred)  +  darkred; 
gcgreen  =■  scl  *  (brightgreen  -  darkgreen)  +  darkgreen; 
gcblue  =  scl  *  (brightblue  -  darkblue)  +  darkblue. 


mapcolorf firstcolor -*-i,  gcred,  gcgreen,  gcblue);  /*  set  the  color 


/*  get  targets’  positions  from  irisl  if  networking.  Otherwise  moves  10  targets 
in  straight  lines,  reversing  when  they  hit  an  edge  */ 


T include  ''fogm.h" 
finclude  "gl.h" 

^include  "math.h" 

# include  <sys/types.h>  /*  contains  the  time  sturcture  tms  */ 
finclude  <sys/times.h>  /*  for  time  calls  */ 

get_tgt  posit  (socket,  designate,  tgt_idx,tgtx,tgty,tgtz,  tank) 

int  socket,  designate,  tgtidx; 
float  *tgtx,  *tgty,  *tgts; 

Object  tank; 

{ 

extern  float  tgt_posiMAX_TGTS][3|; 

extern  float  randx,  randy,  rands; 

extern  Object  target[99j[99); 

extern  short  tgt  gridjdxiMAX  TGTS'12:; 

extern  short  tgt  total,  tgtjiiriMAX  TGTS'; 

short  i.  tgt_num; 

int  nbyte,  addl(); 

float  gnd_level(),  dir,  dx,  dz,  distance; 
long  dist,  d2; 
static  long  seconds; 

static  long  lastsec  =  -999;  /*  -999  is  flag  to  indicate  no  value  */ 

struct  tms  timestruct; 

seconds  =  times(&timestruct); 

if  (lastsec  ==  -999)  /*  compute  distance  targets  move  ahead  * / 
distance  =  0.0; 

else 

distance  =  (float)((15.0/FPS_TO_KTS)*(seconds  -  lastsec)); 

lastsec  =  seconds;  /*  save  for  next  pass  *  / 

for  (i  -  0:  i  <’  tgt  total;  i - )  *  delete  targets  from  old  positions  * 

if  'targetiigi  grid  ;dxit  O'  I  tgt  grid  taxi  I  )  ; 

ielob|(t.irget  tgt  grid  dx  i  Oi  tgt  grid  ox  i  I  j 

target|tgt_grid_idx|i|(Oj||tgt_grid_idx  i  1 1  j  =  U; 

} 

tf  (NETWORKING)  ( 

nbyte  =  read(socket.  iLtgt  total,  sizeof(tgt  total)), 
for  (i  —  0;  i  <  tgt  total;  i+  +  )  { 

nbyte  -  read(socket,  &tgt  grid  idxji  O',  sizeof(short)). 
nbyte  =  read(socket,  &tgt  grid  idx  i  1  ,  sizeof(short)). 


■  t  1.4  | 


I  I'i  •  ft1 *  |  i 


i  |<a  (i.  *1. 


nbyte  =  read(socket,  &tgt_po9;il[0',  siieof(float)) 
nbyte  =  readfsocket.  &tgt_poslijjlj,  siieof(float)) 
nbyte  =  readfsoeket,  Jctgt  poslil(2l,  siieof(float)) 
nbyte  =  read(socket,  &tgt_dirjij,  stseof(short)); 


tgt_total  =  10; 

for  (i  =  0;  i  <  tgttotal;  i++)  { 

dir  =  (float)(tgt_dir(ij  /  10)  *  DTOR; 
tgt_pos[i][0j  +  =  cos(dir)  *  distance; 
tgt _posi ii f 2 1  -=  sin(dir)  *  distance: 
tgtgrid  _idxjil[0)  =  (short)(tgt_posji]j0j/FT_100M); 
tgt_grid  jdx|ijilj  =  (shortj(-tgt_posjij|2|/ FTlOOM); 
if  ((tgt  _posji][0|  >  FTlOK)  ||  (tgt  _pos(ij[0]  <  0))  { 
if  (tgt_dir|ij  >  1800)  tgt_dir|ij  -=  1800; 
else  tgt  dir  i )  --=  1800; 
tgt  postil  1  =  0.0; 

i 

else  if  ((tgt_pos|i|,2|  <  -FTlOK)  n  (tgt  _pos|i||2,  >  0))  ( 
if  (tgt  dir|i,  >  1800)  tgtdirjij  -=  1800; 
else  tgt  dir  i|  -*-  =  1800; 

>gt  pos  I  1  -  1)0 

f 

else  tgt  pos  i  I  -  gnd  levelltgt  pos  r  0  .  tgt  pos  i  2  ) 


i 

if  (’designate)  ( 

if  (NETWORKING)  {  ,  *  find  which  target  >s  designated 

disl  =  up  i((  float )  ( tgt  posOi  O'  -  *  tgt  x  ).2)  * 
up  t((float)(tgt  pos  1 0 1  2  -  *  tgti )  ,2 ) ; 
tgt  idx  =  0. 

for  (i  -  1,  i  <  tgt  total,  i  +  *- )  ( 

d2  =  up  i((float)(tgt  pos  i  0  -  *tgtx).2)  • 
up  i((float)(tgt  post  2  -  *tgtt)  2). 
if  (d2  '  disl)  ( 
dist  =  d2. 


dist  =  d2. 
tgt  idx  (ini)i. 


tff  * 
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«JX  ■! 

X 

\ 

H  IS  *  r 

J  X 

m<i  \ 

v  ' 

** 

■•IS.  f  if  t 

1 X  J 

'mi/ 

num  tgt  total 
for  ( i  O.i-  tgt  num  i  •  ♦ )  ( 

dx  tgt  post  0  •  (floal)tgt  grid  ids  i  t»  *  H  |U)\1 

di  (float )(-tgt  grid  idx  i  1  |  '  KT  l<m\1  tgi  p.>s  i  2 

if  (dx  •  15  0) 

if  (di  15  0)  ( 
add  I  ( i  - 1  o  | 


nMoCvIvV/.  'vLvlv  . 


■p 


addl(i,-l,-l); 

&dd  1  ( i.O,- 1 ) ; 

} 

else  if  (ds  >  313.0)  { 
addl(i,0,l); 
addlli.-l.l): 
add  l|i- 1.0); 

} 

ebe  «ddl(i,- 1,0); 

els«  if  (dx  >  313.0) 
if  (d*  <  15  0)  { 
add  1 1  i.O.- 1 ) 
xddl(i.l.-l); 
addlji.1,0); 

) 

el*€  if  (dt  »  313.0)  { 
addl(i.l.O). 
addlli  .1.1) 
vm  Hiii  i 

I 

f  Iw  addl(i  .1,0), 

*l»«-  if  (di  •  15  0)  add  I  (i.O.  - 1 ). 
i  di  :i;  "i  vidi  i<i 

for  'i  'ii  i«*  total  i  •  •  '  *  tdd  'ar(f  *  to  i,<-w  position* 

f  |lar(»t  'HI  (rid  dx  d  l('  fid  id*  I  I  - 

rditohj) target  i(t  (rid  id*  i  0  t(t  frid  id*  i  1  ) 
pushmatrixl ) 

translatin'  po*  i  0  i((  pot  i  I  1(1  fx>*  I  1  ) 

rotatr(t(t  dir  i  5  I 

'••llobjl  tank  I 
popmatrixl  ) 
r  loanobj)  ) 

) 

»1»*  | 

iar(*l  i(t  (rid  i<f»  i  "  '('  (nd  'dx  I  (*n--bjl  i 

makrohjl tar(rt  i(l  (ri-f  id*  i  "  i(i  (#<d  id*  i  I  I 
pushmatrixl  I 

irantiair|i|t  po*  i  11  (-■*  i  I  if  j  - •*  i  l 

r'.tat»|i(t  dtr  i  5 
■-  allobji  tank  i 


a-M  1 1 1  c  n-ifii  x  i 
•  h'.n  1(1  nit  ii  t  i 

I 


#* i #r r  fl'-ai  '(I  |"'i  VIU  T'.lx 


extern  short  tgtgrid  idx|MAX_TGTS][2j; 
extern  short  tgt  total,  tgtdirjMAXTGToj; 
short  i; 

tgt_pos|tgt  total) [0)  =  tgt_pos[tgt_num||0|;  /*  copy  pos.  for  "new"  tgt  */ 
tgt  posltgt  total)  1 1 1  =  tgt  positgt  numl'li; 

tgt  positgt  total  ; 2  -  tgt  pos  tgt  mim  2': 

tgt  dir  tgt  total  =  tgt  dir  tgt  num'i  /*  copy  dir  for  "new"  tgt  */ 
tgt  grid _idx|tgt  total] |0j  =  tgt  grid  idx[tgt_num]|0]  +  x,  /*  set  pos  in  */ 
tgt  grid  jdx|tgt_totalj(l|  =  tgt  grid  jdxftgt  numjllj  +  s;  /*  new  grid  sq  */ 
for  (i  =  0;  i  <  2;  i  +  +  )  {  /*  reset  if  new  grid  sq  outside  10km  square  */ 

if  Itgt  grid  idx  tgt  total  ii  *-  0)  tgt  grid  idx  tgt  total  i  -  0. 

if  (tgt  grid  idxitgt  total||i|  >  98)  tgt  grid  idx  tgt _totalj|ij  =  98; 


GND  LEVEL 


♦include  "math.h" 
#include  "fogm.h" 
♦define  X  0 
♦define  Y  1 
♦define  Z  2 
float  gnd_level(vx,  vs) 

float  vx,  vs; 


extern  short  gndpixeljlOOjjlOOj; 
float  interp  elev(); 
float  grid_level(); 

float  point  31.  nw  eorner'Sl,  ne  corner  S j ,  sw  comerjSl,  se  corneriS 
float  intersect! 3|; 

dost  »iev 

int  xgrid,  sgrid,  intersect  type; 

/*  determine  which  triangle  the  point  falls  in  * 

xgrid  -  iinti|vx  FT  l()OMi 
igrid  c  inii(-vi  FT  KH)V1), 
if  I  xgrid  •  0|  xgrid  -  0: 
if  (xgrid  •  >♦)  xgrid  -  9A. 
if  (igrid  •  0)  sgrid  -  0, 
if  (sgrid  >  9fl)  jgrid  -  9fl 


if  (xgrid  •  >♦)  xgrid  -  9A. 
if  (igrid  •  0)  sgrid  -  0. 
if  (sgrid  >  9fl)  jgrid  -  9fl 
point  X  vx. 

point  Z  vi, 

nw  orner  X  (float) (xgrid* FT  lOOM) 

nw  corner  Z  -  (float)) (sgrid  1)*FT  lOO.M) 
elev  grid  pixel  sgrid  •  I  xgrid  If  elev  mask, 
nw  corner  Y  pow(elev  ALTSt'ALE). 

iw  corner  X  (float )( xgnd  *  FT  ItKlM) 

xw  corner  l.  (float) (sgrid* FT  100M) 

elev  -  gridpixel  sgrid  xgrd  ♦  elev  mask 
i»  corner  Y  pow(elev  AITS('ALE) 

ne  corner  X  (float)(|xgrid  *  I  I’FT  lOtlVI) 
ne  corner/  I  float )(( sgrid  •  1 1  *  FT  lOOMl 
elev  gridpixel  sgrid  ♦  I  xg  id  *  I  k  elev  mask 
i*»  rn**r  ^  >•»  pjpv  \|  J  s  i  \l  h 

f  r  f-r  \  |oai  I  I  I  <.**  !  *  1  *  I'M 

c  r-er  f.  >al  irg'-l'1'  XlM' 

elev  grulpixel  igrid  xgrid  •  I  k  elev  mask 
ve  corner  N  pow(e|ev  Al.TSt  AI.E) 

if  !  n  |nw  corner  /  i>x  nw  corner  \  ))!  I 

*  point  iv  m  the  lower  triangle  * 

*  find  he  point  of  >nier«e<t  n>n  of  a  line  t  h  rough  \  x  >i 

and  the  vw  corner  with  the  diagonal  * 


line_intersect2(sw_corner,  point,  nwcorner,  se_corner,  intersect, 
icintersect  type); 

/*  find  the  elevation  of  the  intersection  on  the  diagonal  */ 
intersect[Yj  =  interp_elev(nw_comer,  se_corner,  intersect); 

/*  find  the  elevation  of  the  point  vx,  vy  *  j 
return(interp_elev(sw_corner,  intersect,  point)); 

} 

else  { 

/*  point  is  in  the  upper  triangle  */ 

/*  find  the  point  of  intersection  of  the  diagonal  with  a  line 
through  th  ne_corner  and  the  point  */ 
line_intersect2(ne_corner,  point,  nw_corner,  se_corner,  intersect, 
tt intersect  type) ; 

/*  find  the  elevation  of  the  :  rsection  on  the  diagonal  */ 
intersect' Y'  =  interp  elev|nw_corner,  se  corner,  intersect); 

/*  find  the  elevation  of  the  point  vx,  vs  */ 
return(interp  elev(ne  corner,  intersect,  point)); 

\ 


ITS 


EM  THIS  POLY 


# include  "gl.h" 

♦define  X  0 

f define  Y  l 

♦define  Z  2 

♦define  PROPER  2 


int  in_this_poly(polygon,  numvertex,  point) 
float  polygon)  lOj(J|; 
int  num  vertex; 
float  point[3|; 

{ 

int  index; 

int  pt  in,  intersect  type; 

int  num  crossings; 

float  max  x,  max  i,  min  x,  min  s; 

float  intersect!*  ; 

float  old  jntersect  3'.. 

float  start  test  line  3 . . 

max  x  =  polygon  Oj  X  ; 
minx  =  polygon|Oi|X); 
max  *  =  polygonlOijZj; 
min  *  =  polygon  0  Z  . 

for  (index  =  1;  index  <  num  vertex;  *+index)  { 

if  (polygoniindexliX!  <■  min  x)  min  x  =  polygonindex  X], 
if  (polygon  index  Xi  >  max  x)  mu  x  -  polygon  index) [X{ ; 
if  (polygon  index  Z  •  min  *)  min  i  -  polygon  index!  Z  ; 
if  (polygon  index  Z  >  max  i)  max  t  =  polygon  index!  Z 

) 

if  ((point:X,  <  max  x)  44  (point  X  >  mm  x)  44  (point  Z  s.  max  s)  44 
(pointjZ  ■»  min  s))  { 

*  'joint  may  be  polygon,  est  bir’her  by  (instructing  a  ■>eriirai  !ine 

rom  he  'mint  o  \  joint  "Hsnle  he  -lyg'-ns.  mu  nils  ‘  mm  he  •liimoer 
■  1  ’  im«  this  ine  rosses  i  n|e  i  ;  he  ;ml\gon  if  i  rnsse-  in 
odd  nurnoer  ol  times  ihe  point  is  in  me  polygon,  otherwise  n  is 
outside  the  polygon  * 

start  lest  linejX  =  point  X  , 
start  test  line  Z  -  max  *  ♦  1000  0. 

num  crossings  -  0; 
old  intersect  X  -  -999  0; 
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old_intersect[Z[  =  -999.0; 

for  (index  =  0;  index  <  num_vertex  -1;  -M-index)  { 

line_intersect2(start_test_line,  point,  tpolygon'indexHOl, 

4tpolygon(  index-)- 1]|0),  intersect,  &intersect_type); 

/*  if  a  proper  intersection  exists  and  it  is  not  the  same  point 

as  the  previous  intersection  (i.e  it  didn’t  intersect  a  vertex), 
then  add  one  to  the  number  of  crossings  */ 
if  ((jntersect_type  ==  PROPER)  &ik  ((intersect(Xi  !=  oid  intersect(Xj) 
||  (intersectJZ]  !=  old_intersect[Z|)))  rum_crossings  +=  1; 
oldintersectjX]  =  intersect[X|; 
oidintersectjZj  =  intersectjZJ; 

} 

line_intersect2(start_test_line,  point,  &polygon[num_vertex-lj(Oj, 
&polygon|0j[0|,  intersect,  Jtintersecttype); 
if  (intersect  type  ==  PROPER)  numcrossings  +=  1; 

/*  if  the  number  of  crossings  is  even,  the  point  was  outside  */ 
pt  in  =  ((num  crossings  ^  2)  !  =  0); 
ret  urn  (pt  in): 


i 

t 


return(FALSE); 


IN1T  CTRLS 


/  *  initialise  the  operator  controls  * 


4 include  "fogm.h" 

•  include  '  levice  n’’ 

♦  include  "gl.h" 

# include  "math  h" 


*  fog m  constants  * 
graphics  lesice  lehnitions  ‘ 

*  graphics  routine  definitions  " 

*  math  function  definitions  * 


imt  controls(pan.  tilt.  fovy.  alt  greyscale,  compassdir) 


double  "pan, 
double  "tilt, 
mt  "fovy; 

Coord  alt. 
ini  greyscale 
Boat  compassdir 


initial  pan  angle  m  radians  * 

*  initial  tilt  angle  in  radians  * 

*  initial  fieid  of  view  in  tenths  of  degrees  * 

*  initial  altitude  of  missile  " 
initial  value  of  greyscale  boolean  * 

initial  compass  direction 


1 


"pan  •  IN  IT  P\N  *  PTOR 

•■at  ’.NIT  TIL  T  •  ’’T  'K 

••  .V.  .N|T  ."  V. 


*e<  inmai  hi#  in  i  'in  t  te->  -  •  i  >  ‘ 

set  valuator!  \(OCSE!\.  i  short  1 1  IN  IT  P\N*PhNsfc\>  snort  MIN  f 
i  short  I!  VI A  X  PAVPVNSFNS 

sets  aluatori  MO  l  StN  .  short  n  INI  f  I'll  I' ‘  I'll  i  Nt  N>  in,.  r-  MIN 
i  short  )i  VI  A\  TIL  TTIL  TSt  N> 


setv  aluatori  PI  \l  0  i short  i  >  c  >m paasd  .* ‘  I'lK  >(•  \'  -s 
short  liT2t'"PIR>ENS 

set v  aluaior  PI  \  1  4  short  alt  MIN  \  .  f  \|  v  \  t .  1 

set  >  sluatorl'l \L shortnlNIl  d’H  N' 

sh  rt  MIN  -tPFt  P'NPPf  l'NKNs 
short  Mt\  sPFH»"'PFFP<*Nn 


’  hN’P  \N^  N 

ni  r*  ■  .  •  st 


3*  ‘PIKst N 


IN  IT  IRIS 


"  Initialize  the  graphics  environment  for  the  iris  workstation  */ 


^include  "gl  h" 

*inc:uoe  get  n" 

•  include  "fogm  h" 


*  graphics  definitions  */ 

monitor  'ype  definitions  * 
’  fogm  constants  * 


init  iris() 

{ 

ong  *hunk 
ginit  | ) . 

doublebuffer( ) . 
chunk  =  128. 
ohunksi*e(chunkl 

gconhgi  i. 


*  number  of  bytes  be  which  objects 

increment  * / 

*  initialize  the  IRIS  system  */ 

*  put  the  IRIS  into  double  buffer  mode  */ 

*  (means  use  the  above  command  settings)  */ 


setmonuort ,N  1  SG),  *  choose  tv  or  SGI  monitor 

fontdef)  1  ,"TV  font"), 

font(l). 


•  se  «".m  "mt.>r  HZ*'111. 

ursotf  i  ”  rum  ''if  the  -ursor 


backface(TRl'E). 


turn  on  backface  polygon  removal 


IN  IT  TGTS 


#include  "fogm.h" 

^include  "gl.h" 

Lnit  tgts() 

{ 

extern  short  tgt_total; 
extern  Object  target[99](99j; 
short  x,  y; 

int  init_tgt(); 

for  (x  =  0;  x  <  99;  x-r+)  for  (y  =  0;  y  <  99;  y-r-r)  target[xj(y 
if  (1NETWORKING)  { 
tgt  total  =  10; 
init  tgt(0,9.8,3.5,1295); 
init  _tgt(  1 ,9. 5,3.5, 1295) ; 
init  tgc(2,9.4.3. 1,1295); 
init  tgt (3, 9. 8, 0.5, 1800); 
init_tgt(4,9.5,0.0,1355); 
init_tgt(5, 8. 0,0. 0,1445); 
init  cgc(6, 4. 0.0. 0.1450); 
imt  tgt (7, 0.0. 0.5. 450); 
init  tgt (8,9. 5, 9. 8. 2700); 
init  tgt  (9, 9. 8, 8. 5. 1800); 

} 

} 

init  tgt ( tgt _num, xoffset, zoffset, direction) 

short  tgt_num,  direction; 
float  xoffset,  zoffset; 

{ 

extern  short  tgt_dir[MAX_TGTSj; 
extern  float  tgt_pos[MAX_TGTS](3j; 

tgt_pos[tgt_num][0]  =  xoffset  *  FEETPERGRID; 
tgt_positgt_numj[2]  =  -zoffset  *  FEETPERGRID; 
tgt  dirltgtnum]  =  direction; 
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INTEtP  ELEV 


tinrlade  'maih  h " 

adeflne  X  n 
•dehne  t 
» leh  n»  l  2 

Iu4t  interp  elev(liae  iivt  line  end  point  i 

floai  me  '<«/■<  ’  on*  »rx  1  Z  ;«n  I 

< 

long  float  lift*  della*  line  deltas  point  delta*  point  deltas 
float  line  length,  dint  to  point 
float  interpolation 

line  deltax  -  Hong  float)(hne  end  X  line  ilart  X  ) 

me  iettat  Ion*  io*c  line  -no  Z  one  *i»ri  Z 

point  delta*  -  (long  float  ((line  itart  X  -  poialX  ) 
point  delta*  =  (long  float |{ line  start |Z  •  point  Z  ), 

line  length  i  float  ihypotl  line  delta*  une  leitan 
dial  to  point  -  ( float  | hy poll  point  deltax  point  dellasl 

interpolation  =  line  start! Yj  *  ((line  end  Y  -  line  start jY;) 
(dint  to  point /line  length)) 


ret  urn  ( in  terpolat  ion ) . 


LK.HTOHIE.NT 


*  this  hi.  '  * 


It  It  •  '■'Mjllfl*  'h4t  'Oftl  pUCS  lighting  for  a  polygon  ba»s»d 
upon  lh.  4*| It  between  the  Norm*!  vector  of  ih»  polygon 
tnii  lh.  dirwtKin  lo  lh.  light  source 

lighion.nl 1  *\ /  n<  o.»rd»  ax  »v  u  I*  ly  If  <-<»lormin  '•,,|,)rtri44  '•olortout.i 
xy*  3  flo4(mg  '  'joHi  of  lh.  polygon 
n coords  number  of  coordinates 

u,4y  u  -  interior  point  of  th*  whole  object  Used  to  determine 
miward  !a<  ing  normal  of  in.  polygon  TH  is*  .s  <  h.  nmr 
point  ol  r.ler.nce  inti  would  o«  used  for  backface 
polygon  removal 

lx.iy.lx  -  'ector  pointing  in  direction  >f  'he  hgnt.  source 

colormin.  colormax  =  indices  used  for  the  colors  assigned  io  this 
polygon.  The  user  is  responsible  for  setting 
up  the  color  ramp 

colortouse  =  returned  color  used  to  light  the  polygon. 

Note:  the  routine  also  puts  the  polygons  out  ordered  counterclockwise 
with  respect  to  the  interior  point  for  ease  of  backface  polygon 
removal. 


7 

finclude  <math.h> 
finclude  <gl.h> 
fdefine  MAXCOORDS  80 
^define  PIDIV2  1.570796327 

float  txy*|MAXCOORDS||3);  /*  temp  coord  hold  */ 


lightorient(xy  z,  ncoords,  ax, ay,  az,ix,ly, lx, colormin, colorm  ax, colortouse) 

float  xyz(](3]; 
long  ncoords; 


w. 

t£ 


i 

yS. 

•Ji, 

l*V 


I 

$.1 


Sou  ax. ay, as,  ,  *  interior  point  of  the  whole  object  * 
float  U.ly.ls,  /*  direction  to  the  light  source  *, 
long  colormin.colormax,  /*  color  mm.  mu  indices  */ 

ong  *  olortouae:  *  <-olor  useo  to  light  the  polygon  return  .-aiuei 


long  ij;  /*  loop  tempe  */ 

long  npoly  _onent(),  /•  direction  test  function  */ 

float  vl|3|,v2(3|;  /*  vectors  used  to  compute 

the  polygon's  normal  */ 


float  normaljSj, 
float  normalmag; 
float  lightmag; 


double  dotprod: 


float  radians; 


/*  the  polygon’s  normal  */ 
i  *  normal's  magnitude  " , 
j*  magnitude  of  the  light  vector  */ 
,  ’  lot  product  of  N  and  L  * 

*  angle  between  N  and  L  ", 


/*  check  the  number  of  coords  in  the  input  array  */ 
if(ncoords  >  MAXCOORDS) 

{ 

printf("LIGHTORIENT:  too  many  coords  passed  to  me!  =  %d0, ncoords); 
exit(l); 

} 

/*  orient  the  polygon  so  that  its  counterclockwise  with  respect 
to  the  interior  point  */ 

if(npoly_orient(ncoords,xyz,ax,ay,az)  ==  1) 

{ 

/*  the  polygon  is  clockwise,  reverse  it.  */ 

for(i=0:  i  <  ncoords;  i=  i-^  1) 

i 

1 

for(j=0;  j  •  3;  j=j-rl) 

{ 

txyz[i]|jj  =  xyz[ncoords-i-lj[jj; 


for(i=0;  i  <  ncoords;  ++i) 
for  (j=0;  j  <  3;  ++j) 
xyz|i](j|  =  txyz[i)(j]; 


'Viv.v’vv/vy.-.'-. 


V*.  ^ 


} 

!*  the  coordinate*  ire  ordered  counterclockwise  in  array  xy*  V 

/*  compute  the  normal  vector  for  the  polygon  using  the  first 
three  vertices.  *  / 


.w 


/*  compute  the  first  vector  to  use  in  the  computation  •/ 
v  1 10|  =  *y»[2|(0|  -  xyi|l|[0|; 


vl|l)  =  xyi|2||l]  -  xys|l)|l] 
vl|2)  =  xym(2|[2]  -  xyaji||2 


/*  compute  the  second  vector  to  use  in  computing  the  normal  */ 
v2j0|  =  xysjOjjO]  -  xyzjljjO), 


v2(lj  =  xy*jO|[l]  -  xyi|l)[l 
v2|2)  =  xysj0]j2)  -  xyi| l)|2) 


/*  the  normal  is  vl  x  v2  */ 

normallOl  =  vl:li*v2'2i  -  vl  2i*v2ll!; 

normal]  1J  =  vl|2j*v2|0|  -  vl|0j*v2|2j; 
normal[2|  =  vl[0|*v2[l|  -  vl|l|*v2(0|; 


*  compute  the  magnitude  of  the  normal  *  ' 
normalmag  =  $qrt|(normailOl*normal|Oi)-'-(normaljl;*normallli)- 
( normal!  2l"normall2i)); 


/*  check  the  magnitude  of  the  normal  */ 
if(  normalmag  ==  0.0) 

{ 

normalmag  =  0.00001;  /*  a  small  number  */ 

} 


/*  compute  the  light  mag  */ 
lightmag  =  sqrt((lx*lx)  +  (ly*ly)  +  (lz*lz)); 


if(lightmag  ==  0.0) 

{ 

lightmag  =  0.00001;  /*  a  small  number  */ 

} 


/*  compute  N  .  L  (normal  dot  product  with  the  light  source  direction)  */ 
dotprod  —  (normallOl  *  lx)  *  (normalili  *  ly)  -t  (normal(2l  *  Iz); 


dotprod  —  dotprod/flightmag’normalmag); 


/*  dotprod  =  cos(theta)  of  the  angle  between  N  and  L. 

Convert  to  angle  in  radians  */ 
radians  =  acos(dotprod); 


/*  compute  the  color  we  should  use  */ 
if(-PIDIV2  <=  radians  bit  radians  <=  PIDIV2) 
{ 
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/*  if  the  sngie  is  negative,  w>i  to  positive  * 
if(rsdi*ns  <  0  0) 

{ 

riduns  =  -rsdisns, 

) 

'■olortouse  =  ((coiormax-'otormin)  P1D1  V2|* !  PIUIV  i-rsdisns]  -  cmormin 

I 

else 

{ 

*colortouse  =  colormm; 

} 

/*  set  the  color  */ 
color  ( ‘colortouse) ; 

/*  draw  the  poly  */ 

/*  polf(ncoords,txyi);  */ 


LINE  INTERSECT? 


^include  "(I  h  ' 

idtliif  X  o 

•  deline  l  l 
^define  NONE  0 
#deflne  INTERSECT  I 
#delne  PROPER  2 


line  inter*ecl2( start!,  endl,  itirt],  end2,  intersect, 
intersect  type) 

float  dart  1  31,  endlS  ,  (tart2ISj,  end2|3|,  intersect|3j, 
int  ‘intersect  type; 

\ 

/  *  given  two  lines  of  the  form  s  =  mx  ■+•  b  and  i  =  nx  -r  c, 
solving  for  x  when  the  s’t  are  equal  gives  x  =  (c- b) /  (m-n). 

Then  solve  for  i  using  x  in  either  of  the  above  equations.  */ 

float  m.n.b.c; 

float  mini  x.  mm2  x,  maxi  x,  max2  _x,  mini  z.  mm2  z.  maxi  z,  max2  z: 

•intersect  type  =  PROPER; 

/*  slope  and  z  intercept  of  linel  */ 
if  (endl(X|  !=  startl(X|)  { 

m  =  (end  1  ( Z |  •  startl(Z|)/(endl(X|  -  startljX]); 

b  =  ((startl[Z|  -  end  1  [ Z ] ) / ( end  1  [ X |  -  startljX]))  *  startljX]  +  startljZj; 
if  (end2[X|  !=  start2(X|)  {  /*  both  lines  are  non-vertical  */ 

/*  slope  and  i  intercept  of  line2  */ 
n  =  (end2[Zj  -  start2jZj)/(end2(X]  -  start2[X]); 
c  =  ((start2[Z|  -  end2[Z])/(end2jX|  -  start2jX]))  *  start2|X]  + 
a  t  art  2  f  Z  ] ; 


if  (m  !=  n)  { 

intersectjX]  =  (c-b)/(m-n); 
intersectjZ]  =  m*  intersectjX]  +  b; 

} 

>dse  {  *  both  lines  have  equal  slopes  *  ' 

'intersect  type  =  NONE; 

} 

} 

else  {  /*  linel  is  non-vertical,  line2  is  vertical  */ 
intersectjX]  =  end2(X]; 
intersectjZ]  =  m*intersect[X]  4-  b; 

} 

} 

else  { 
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if  (endliX  !*  ttart2  X|)  {  *  lin« I  it  vertical,  Iine2  it  non-vertic  al* 

/*  ilop*  and  t  intercept  of  line]  * 
n  =  (end2  Zl  ■  atart2  Zl)  (end2X  -  ttart2!X  ). 
c  =  ((ttnrti  Z,  -  end2|Z,)/  (end2,  X  -  startljX,))  *  tiari2X,  i- 
•tnrt2jZi; 

intersect!  X  -  endl'XI; 
intersect  Z  -  nVnlersect  X  - 

l 

else  {  /*  both  linet  Are  vertical  */ 

‘intersect  type  =  NONE; 

} 

} 

if  (‘intersect  type  !=  NONE)  { 

/*  see  if  the  intertection  is  proper,  or  if  only  the  extensions  of  the 
line  segments  intersect  */ 
if  (startl[Xj  <  endl[X|)  { 
minlx  =  stArtl|X|; 
max  lx  =  endl[Xj; 

} 

else  { 

minlx  =  endl(X|; 
maxi  x  =  start  1[X{; 

} 

if  (sc&rtl ;Z)  <:  endl'Z  )  { 
mini  I  =  start liZI; 
maxlz  -  endl'Z]; 

} 

else  { 

mini*  =  end  1  [Z]; 
maxi*  =  startl(Z); 

} 

if  (start2[X]  <  end2[X])  { 
min2_x  =  start2(X]; 
max2_x  =  end2|X); 

} 

else  { 

min2_x  =  end2(X]; 
max 2  x  =  start2(X]; 

} 

if  (start2[Zj  <  end2[Z|)  { 
min2_x  =  start2[Z]; 
max 2  z  =  end21  Z 1 ; 

} 

else  { 

min2_z  =  end2]Zj; 
max2  z  =  start2iZj; 

} 


*  *  •  ■  *  *  •  > *  .  • » *  •  ■ 
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if  (( interact  I  Xi  <  =  max  1  x)  bb  (inieracct  X  <  =  mtx2  x)  LL 

(interaacijXi  >=  mini  x)  kb  (interaextjX  >=  mm2  x)  bb 

(interaactlZI  <=  max  1  i)  bb  (interaectiZ!  <  max]  i)  bb 

(int«rMct|Zi  > -  mini  »)  bb  (inl«ra«ci;Z|  >=  min2  i)j  { 

‘interaect  typ«  =  PROPER; 

\ 

ela«  j 


interaect  type  =  INTERSECT; 


MAKENAVBOX 


/*  drawnavbox.c  -  this  function  is  called  by  the  FOG-M  missile  simulator  to 
build  an  object  on  top  of  the  contour  map  in  the  upper  right-hand  corner 
of  the  screen.  Navbox  ■-ontains  the  direction  arrow  and  view  box  in  red.  */ 

f  include  "gl.h" 

#  include  "fogm.h" 

#  include  "device. h" 

drawnavbox(navbox,  arrowtag) 

Object  *navbox; 

Tag  ‘arrowtag; 

{ 

*navbox  =  genobj();  /*  create  the  navigation  contol  and  display  object  */ 

makeobj  ( *  nav  box ) ; 

if  (TV)  viewport(475, 635,523, 474); 

else  viewport(768. 1023, 512. 767);  /*  upper  right  hand  corner  of  screen  */ 
pushmatrix();  /*  draw  arrow  in  feet  coordinates  */ 

ortho2(-10. 0,10.0  +  NUMXGRIDS*FEETPERGRID,  -10.0, 

-10.0  -  NUMZGRIDS*FEETPERGRID); 

color(BLACK); 

clear(); 

color(128); 

*  arrow  tag  =  gentag(); 

maketag(*arrowtag); 

move2(0.0,0.0); 

draw2(0.0,0.0); 

draw2(0.0,0.0); 

move2(0. 0,0.0); 

draw2(0.0,  0.0); 

rect(0.0,0.0,0.0,0.0);  /*  view  box  */ 

popmatrixf); 

closeobj(); 


I*,  t*.  i  „  >i 


»i.  »•  ji  ft  .  ji .  |i  *(  »i 


MAKEINDBOX 


/*  makeindbox.c  is  a  function  that  creates  an  object  that  displays  the  control 
idicators  for  the  FOG-M  missile  simulation  */ 

finclude  "gl.h" 
finclude  "fogm.h" 

makeindbox(indbox,headingtag,elevtag,altmsltag,speedtag,zoomtag,ti]ttag, pantag, desigtag) 
Object  ‘indbox; 

Tag  ‘headingtag,  *elevtag,  ‘speedtag,  ‘zoomtag,  ‘tilttag,  ‘pantag,  ‘desigtag; 

Tag  ‘altmsltag; 

{ 

‘indbox  =  genobj(); 

makeobj( ‘indbox); 

if  (TV)  viewport(475, 635,162,322); 

else  viewport(768, 1023, 256,511);  /*  middle  box  on  side  of  screen  */ 

pushmacrix(); 

ortho2(0. 0,255. 0,0. 0,255.0);  /*  use  screen  sized  coordinates  */ 

color(854);  /*  clear  the  window  */ 

clear(); 

linewidth(2); 

color(BLACK); 

recti(0, 0,255, 255);  /*  outline  box  */ 

color( YELLOW);  /*  print  labels  for  readouts  */ 

cmov2i(  10,240); 

charstr("SPEED"); 

cmov2i(55,225); 

charstrC'kts"); 

cmov2i(90,240); 

charstr("HEADING"); 

circ(  140.0,232.0,3.0);  /*  "degree"  symbol  */ 

cmov2i(180,240); 

charstr("AIt  AGL");  /*  AGL  =  above  ground  level  */ 

cmov2i(225,225); 

charstr("ft"); 

cmov2i(  180,200); 

charst,r("  Alt  MSL'');  /*  MSL  =  mean  sea  level  */ 

cmov2i(225.185); 

chars  t,r("ft"); 

cmov2i(50,130); 

charstr("ZOOM"); 

move2i(45,200);  /*  draw  slider  bar  frame  */ 

draw2i(25,200); 

draw2i(25,70); 

draw2i(45,70); 

cmov2i(  15,196); 


charstr("8");  /*  label  slider  bar  values  * 

cmov2i(6,170); 

charatr("15”); 

cmov2i(6,144); 

charstr("25"); 

cmov2i(8.118): 

charscrCSS'’); 

cmov2i(8,92); 

charstr("45"); 

cmov2i(6,66); 

charstr("55"); 

color(WHITE);  /*  readouts  in  white...  */ 

cmov2i(10,225);  /*  initialize  to  dummy  values  */ 

*speedtag  =  gentag(); 
maketag(*speedtag); 

charstr("  200");  /*  speed  */ 

cmov2i(  108.225); 

*headingtag  =  gentag(); 

maketag(*headingtag); 

charstr("  0");  /*  heading  */ 

cmov2i(l80,225); 

’elevtag  =  gentag(); 
maketag(*elevtag); 

charstr( "  1000") ;  /*  altitude  above  ground  level  */ 

cmov2i(180,185); 

*altmsltag  =  gentag(); 
maketag(*altmsltag); 

charstr("1000M);  /*  altitude  from  mean  sea  level  */ 

color(RED); 

*zoomtag=  gentag();  /*  indicator  for  zoom  slider  bar  */ 

maketag  ( *  zoomtag) ; 

move2(28.0, 155.0); 

rdr2(10. 0,5.0); 

rdr2(0.0,-10.0); 

rdr2(- 10. 0,5.0); 

popmatnxi ); 

if  (TV)  viewport(0, 474, 0,474);  /*  reset  for  heads-up  display  */ 

else  viewport(0, 767, 0,767); 

pushmatrix(); 

ortho2(0. 0,767. 0,0. 0,767.0);  /*  use  screen  sized  coordinates  */ 

color(WHITE); 


I 

t 


I 

I 

I 

I 


if  (TV|  linewtdtht  2i , 
els*  Unewidthf  1) 

r«ctfi(365,370,370.375).  *  dr**  center  ,>t  ru»hiin 

rectfij  396, 370, 40 1,375) 
r*ctSI365.391  370  396). 

r«c  1.0(396.591  401.396). 
move2i|0.38S). 

draw2i(360,S83).  *  draw  crosshairs  * 

move2i(406,383), 

draw2i(767,383); 

mov*2il 383  0) . 

draw2i(383,365); 

move2i(383,401); 

draw2i(383,767); 

linewidth{2), 

mov<*2u 30.50);  *  draw  TILT  slider  bar  frame 

draw2i(40,50); 
draw2i(40,680); 
draw2i(30,680); 

cmov>i(0,676); 

charstr("-*-25'');  *  label  slider  bar  values 

cmov2i(0.613); 
charstr("~ 20"); 
move2i(30,617); 
draw2i(40,6l7); 
cmov2i(0,550); 
charstr("  +  15"); 
move2i(30,554); 
draw2i(40,554); 
cmov2i(0,487); 
charstr("  +  10"); 
move2i(30,491); 
draw2i(40,491); 
cmov2i(0,424); 
charstr("  +5"); 
move2i(30,428); 
draw2i(40,428); 
cmov2i(0,361); 
charstrl"  0"); 
m  ove2ii30.365); 
lraw  2i(  40, 3651; 
cmov2i(0,298); 
charstr("  -5"); 
move2i(30,302); 
draw2i(40,302); 
cmov2i(0,235); 
charstr("-10"j; 
move2i(30,239); 
draw2i(40,239); 
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cmov2i(0,l72); 

chamr("-15"): 

move2i(30,176); 

draw2i(40,l76); 

cmov2i(0,109); 

charstr("-20"); 

move2i(30. 1 13); 

draw2i(40,113); 

cmov2i(0,46); 

charstr("-25"); 

‘tilttag  =  gentag(); 
maketag('tilttag); 
move2(42. 0,365.0); 
rdr2(10.0,-5.0); 
rdr2(  0.0,10.0); 
rdr2(-8.0,-4.0); 
rdr2(  6.0, -3.0); 
rdr2(  0.0,  4.0); 
rdr2l-2.0,-1.0); 
rdr2(  1.0, -1.0); 


move2i(  120.15); 

araw2i(  120,25); 

draw2i(750,25); 

draw2i(750,15); 

cmov2i(l07,3); 

charstr("-25"j; 

cmov2i(l70,3); 

charstr("-20"j; 

move2i(l83,15); 

draw2i(183,25); 

cmov2i(233,3); 

charstr("-15"); 

move2i(246,15); 

draw2i(246,25); 

cmov2i(296,3); 

charstr("-10"); 

move2i(309,15); 

draw2i(309,25); 

cmov2i(363,3); 

oharstr("-5"); 

move2n'372. 15); 

iraw2il372.25); 


■'*  indicator  for  TILT  slider  bar  */' 


*  draw  PAN  slider  bar  frame 


/*  label  slider  bar  values 


cmov2i(431,3); 
charstr("0"); 
move2i(435,15); 
draw2i(435,25); 
(.mov2i(494,3); 
charstr("-*-5"); 
move2i(498, 15); 
draw2i(49«  25). 
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cmov2i(552,3); 

charatrC+lO”); 

move2i(561,15); 

draw2i(561,25); 

cmov2i(615,3); 

ch«rstr("+15M); 

mov«2i(624,15); 

draw2i{624,25); 

cmov2i(678,3); 

charstr("+20"); 

move2i(687,15); 

draw2i(687,25); 

cmov2i(741,3); 

charstr("+25"); 

*  pan  tag  =  gentag();  /*  indicator  for  PAN  slider  bar  */ 

maketag(*pantag); 

move2(435. 0,27.0); 

rdr2(  5.0,10.0); 

rdr2(-10.0,  0.0); 

rdr2(  4.0, -8.0); 

rdr2(  3.0,  6.0); 

rdr2(  -4.0,  0.0); 

rdr2(  1.0, -2.0); 

rdr2(  1.0,  1.0); 

move2i(0,30);  /*  designate/reject  box  *  / 

draw2i(  100,30); 
draw2i(  100,0); 

•desigtag  =  gentag(); 
maketag  ( *  desigtag) ; 
cmov2i(10,10); 

charstr("DESIGNATE"); 

popmatrix(); 

closeobj(); 


MAKEINSTRBOX 


/*  makeinstrbox.c  •  this  function  builds  an  object  that  contains  an  instruction 
summary  for  the  FOG-M  missile  simulation  */ 

^include  "gl.h" 

#  include  "fogm.h" 

makeinstrbox(instrbox) 

Object  ‘instrbox; 

{ 

*instrbox  =  genobjQ; 

makeobj  ( *  instr  box) ; 

if  (TV)  viewport(475, 635, 0,161); 

else  viewport(768, 1023, 0,255);  /*  box  is  in  lower  right  hand  corner  * / 

pushmatrix(); 

ortho2(0.0, 255.0, 0.0, 255.0);  /*  use  screen-sised  coordinates  */ 


color(851);  /*  use  a  medium  green  */ 

clear(); 

iinewidth(2); 


color(852); 
rectfi(10,20,110,195); 
rectfi(135,80,245,195); 
color(BLACK); 
recti(  10,20, 110, 195); 
recti(135, 80,245, 195); 
recti(0, 0,255, 255); 


/*  use  light  brown  */ 

/*  draw  the  mouse  control  box  */ 
/*  draw  the  dial  control  box  */ 
/*  outline  controls  */ 


color(BLACK); 

cmov2i(60,230); 

charstr("C  O  N  T  R  O  L  S"); 

cmov2i(37,200); 

charstr  ( "MOUSE") ; 

cmov2i(172,200); 

charstr(”DIALSM); 

cmov2i(25.60); 

charstr("TILT"); 

move2i(70.82);  -  *  draw  arrow  *  ' 

draw2i(75,55); 

draw2i(75,75); 

draw2i(70,68); 

move2i(75,75); 

draw2i(80,68); 

move2i(75,55); 

draw2i(80,62); 


cmov2i(25,30); 

charstr("PAN"); 

move2i(67,40);  /*  draw  arrow  */ 

draw2i(60,35); 

draw2i(80,S5); 

draw2i(73,40); 

move2i(80,35); 

draw2i(73,30); 

move2i(60,35); 

draw2i(67,30); 

color(85S);  /*  dark  brown  */ 

rectfi(20,85,40,185);  /*  draw  mouse  buttons  */ 

rectfi(50, 85,70, 185); 
rectfi(80,85, 100,185); 

color(BLACK);  /*  outline  buttons  */ 

recti(20,85,40,185); 

recti(50,85,70,185); 

recti(80.85.100,185); 

color  (853); 

circfi(160,165,20);  /*  draw  dials  */ 

circfi(160,110,20); 

circfi(220,165,20); 

circfi(220,110,20); 

color(BLACK);  /*  outline  dials  */ 

circi(  160, 165,20); 

circi(160,110,20); 

circi(220, 165,20); 

circi(220, 110,20); 

color(  WHITE); 

cmov2i(l47,160); 

charstr("SPD");  /*  label  dials  */ 

cmov2i(147,106); 

charstr(''DIR"); 

cmov2i(207,106); 

charstrCALT”); 

cmov2i(207,160); 

charstr("CLR"); 

cmov2i(25,l70); 

charstr("Z");  /*  label  mouse  buttons  */ 

cmov2i(25.158); 

charstr(  "O"); 

cmov2i(25,146); 

charstr(M0"); 

cmov2i(25,134); 

charstr("M"); 

cmov2i(25,110); 

charstr("I"); 

cmov2i(25,98); 

charstr("N"); 


cmov2i(55,170); 

charstr("D"); 

cmov2i(55,158); 

chantr("E"); 

cmov2i(55,146); 

chantrCS*1); 

cmov2i(55,134); 

charstr("I"); 

cmov2i(55,122); 

ch«r»tr("G"); 

cmov2i(85,170); 

charstrC'Z"); 

cmov2i(85,158); 

charstr("0"); 

cmov2i(85,146); 

charstr("0"); 

cmov2i(85,154); 

charstr("M"); 

cmov2i(85,110); 

charstr(nO"); 

cmov2i  (85,98); 

charstr("U"); 

cmov2i(85,86); 

charstr("T"); 


} 


popmatrix(); 

closeobjQ; 


MAKEMAP 


/*  makemap.c  •  this  function  is  called  by  the  FOG-M  missile  simulator  to 

build  an  object  containing  a  contour  map.  The  map  is  used  for  the  full 

screen  display  in  prelaunch,  and  in  the  upper  right  corner  of  the  flight 

display  in  fogm.  */ 

« 

^include  "gl.h" 

^include  "fogm.h” 

# include  "device.h" 


makemap(contour) 

Object  *contour; 

{ 

short  i,  j,  elev,  length,  lastcolor,  breakpt[l5]; 
int  colour; 

extern  short  gridpixel[lOOj[lOO];  /*  terrain  elevations  Si  vegetation  */ 


/*  compute  elevations  where  color  changes  should  occur  */ 

for  (i  =  1;  i  <  16;  i++)  breakpt[i-l]  =  (((MAX  -  MIN)  /  16  )  *  i)  +  MIN; 


‘contour  =  genobj();  /*  create  the  navigation  contol  and  display  object  */ 
makeobj( ‘contour); 
viewport(0,767, 0,767); 
pushmatrixQ; 

ortho2(0.0, 100.0,0.0, 100.0);  /*  use  array  index  space  */ 

color(BLACK); 

clear(); 

lastcolor  =  BLACK; 
linewidth(8); 


for  (i=0;  i  <  100;  ++i)  {  /*  draw  column  i  */ 

move2i(i,0);  /*  start  at  bottom  of  column  */ 

length  =  0;  /*  #  adjacent  points  of  the  same  color  */ 

for  (j  =  0;  j  <  100;  ++j)  {  /*  for  each  row  in  column  i  */ 

elev  =  gridpixel[j)ji|  Sc  elevjnask;  /*  mask  off  veg  code  */ 

if  (elev  <  breakpt(Oj)  colour  =  16;  /*  assign  green  colors  */ 

else  if  (elev  <  breakpt(lj)  colour  =  17; 

else  if  (elev  <  breakpt|2i)  colour  =  18; 

else  if  (elev  <  breakptlSI)  colour  =  19; 

else  if  (elev  <  breakptl4!)  colour  =  '20; 

else  if  (elev  <  breakpt[5j)  colour  =  21; 

else  if  (elev  <  breakpt{6j)  colour  =  22; 

else  if  (elev  <  breakpt[7j)  colour  =  23; 

else  if  (elev  <  breakpt[8])  colour  =  24; 

else  if  (elev  <  breakpt[9j)  colour  =  25; 

else  if  (elev  <  breakptjlO))  colour  =  26; 

else  if  (elev  <  breakpt(llj)  colour  =  27; 

else  if  (elev  <  breakpt[l2j)  colour  =  28; 
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else  if  (elev  <  breakpt(lS|)  colour  =s  29; 
else  if  (elev  <  breakpt|l4j)  colour  %  SO; 
elae  colour  =  SI; 

/*  if  veg-code  =  0  (i.e.  veg  <  1  meter)  shift  to  brown  colors  */ 
if  (!((gridpixel(j)(ij  >>  IS)  k  vegmask))  colour  +=  16; 

if  (colour  ==  lastcolor)  Iength++;  /*  don’t  draw  yet  */ 
else  {  /*  draw  now  that  color  has  changed  */ 

color  (lastcolor); 
rdr2i(0,  length); 

lastcolor  •=  colour;  /*  reset  for  new  draw  * / 

length  =  1; 

} 

}  /*  end  for  j  */ 

color(colour);  /*  draw  last  (top)  line  */ 

rdr2i(0,length); 

}  /*  end  for  i  */ 

if  (!TV)  { 

color(BLACK);  /*  draw  grid  on  top  of  map  */ 

linewidth(l); 

for  (i  =  10;  i  <  100;  i-r-  =  10)  {  /*  draw  interior  lines  */ 
move2i(i,0);  j*  horisontals  */ 

draw2i(i,100); 

move2i(0,i);  /*  verticals  */ 

draw2i(100,i); 

} 

} 

linewidth(2);  /*  draw  exterior  border  */ 

rect(0.0,0.0, 100.0, 100.0); 

popmatrixQ; 

closeobj(); 
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MAKESCREENS 


/*  makescreens.c  •  builds  graphical  objects  for  prelaunch’s  instructional 

screens  and  readout  boxes.  */ 

#  include  "gl.h" 

# include  "device.h" 

£  include  "fogm.h" 

makescreens(obj,tag) 

Object  obj[7|; 

Tag  tag[6]; 

{ 

objjINSTR)  =  genobj();  /*  object  for  pre-launch  instructions  */ 

makeobj(obj|INSTR|); 

if  (TV)  viewport(475, 635, 239,474); 

else  viewport(767, 1023, 385,767); 

pushmatrix(); 

ortho2(0.0, 255.0, 0.0.384.0); 

color(CYAN); 

clear(); 

color(BLUE); 

rectfi(10,10,245,374); 

color  (WHITE); 

cmov2i(30,340); 

charstr("PRE-LAUNCH  INSTRUCTIONS”); 
cmov2i(25,300); 

charstr("l.  PRESS  LEFT  MOUSE"); 
cmov2i(52,285); 

charstr(”BUTTON  TO  LOCK  IN"), 
cmov2i(52,270); 

charstr( "LAUNCH  POSITION"); 
cmov2i(25,220); 

charstr("2.  PRESS  RIGHT  MOUSE"); 
cmov2i(52,205); 

charstr( "BUTTON  TO  LOCK  IN"); 
cmov2i(52,190); 

charstrP’TARGET  LOCATION"); 
cmov2i(25.140); 

<  harstri"3.  PRESS  MIDDLE  MOUSE"); 
cmov2i(52,125); 

charstr("BUTTON  TO  LAUNCH"); 
cmov2i(25,  75); 

charstr("4.  PRESS  ALL  THREE"); 
cmov2i(52,  60); 

charstr("BUTTONS  TO  EXIT"); 

popmatrix(); 

closeobjQ; 
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/*  define  object  for  displaying  user  input  for  missile  launch 

position  and  target  location.  Also  displays  computed  heading 
and  distance  to  target  *  / 

obj[STATS]  =  genobj(); 

makeobj  (obj  [ST  ATS  | ) ; 

if  (TV)  viewport(475, 635,0,238); 

else  viewport(767, 1023, 0,384); 

pushmatrixQ; 

ortho2(0.0, 255.0, 0.0, 384.0); 

color  (CYAN); 

clear(); 

color(BLUE); 

rectfi(10, 10,245,374); 

color(  WHITE); 

cmov2i(30,340); 

charstr("PRE-LAUNCH  STATISTICS”); 
cmov2i(25,260); 

charstr("LAUNCH  POSITION:  10SFQ"); 

cmov2i(70,235); 

charstr("X  COORD:  "); 

cmov2i(70,220); 

charstr("Y  COORD:  ”); 

cmov2i(  170,235); 

tag(LAUNCH]  =  gentagQ; 

maketag(tag[LAUNCH]); 

charstr("  "); 

cmov2i(170,220); 

charstr("  "); 

cmov2i(25,180); 

charstr("TARGET  LOCATION:  10SFQ"); 

cmov2i(70,155); 

charstrC'X  COORD:  "); 

cmov2i(70,140); 

charstr("Y  COORD:  "); 

cmov2i(170,155); 

tag[TARGET]  =  gentag(); 

maketag(tag[TARGET[); 

charstrC  ”); 

cmov2i(170,140); 

charstr("  "); 

cmov2i(25.100); 

chamr( "HEADING:  '); 

cmov2i(25.60); 

charstr( "DISTANCE:  "); 

cmov2i(106,100); 

tag[HEADj  =  gentag(); 

maketag(tag[HEAD|); 

charstr("  "); 

cmov2i(  115,60); 

charstr("  "); 

popmatrix(); 
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closeobj(); 

/*  define  object  for  lines  k  circles  showing  flightpath  on  contour  map 

obj[FLTPATH]  =  genobj(); 

makeobj(obj|FLTPATHj); 

pushmatrixQ; 

if  (TV)  viewport(0, 474, 0,474); 

else  viewport(0, 787, 0,787); 

ortho2(0.0, 100.0, 0.0, 100.0); 

colorf  BLACK); 

clear(); 

color(64); 

linewidth(S); 

tag(MISSILE]  =  gentag(); 
maketag(tag  [MISSILE]); 
circf(0.0,0. 0,0.0); 
move2(0.0,  0.0,  0.0); 
draw2(0.0,  0.0,  0.0); 
color(128); 

tag[TGT]  =  gentag(); 
maketag(tag(TGT|); 

circf(0. 0,0.0, 0.0); 

popmatrixQ; 

closeobj(); 

/*  define  object  for  displaying  first  screen  of  operator  instructions  */ 

objjSCREENl]  =  genobjQ; 
makeobj(obj(SCREENl|); 

color(BLUE);  /*  set  background  color  */ 

clear  (); 

color  (RED); 

linewidth(lO); 

recti(0, 0,1023, 767); 

linewidth(l); 

color(  WHITE); 

cmov2i(420,500); 

charstr("  WELCOME”); 

cmov2i(420,450) ; 

charstr("TO  THE"); 

cmov2i(320.400); 

charstri"  FIBER-OPTIC  ALLY  GUIDED  MISSILE")-. 

<:mov2i(420.350); 

charstr("(FOG-M)"); 

cmov2i(410,300); 

charstr("SIMULATION"); 

emov2i(310,100); 

charstr("PRESS  MIDDLE  MOUSE  BUTTON  TO  CONTINUE..."); 
cmov2i(315,85); 

charstr("OR  PRESS  ALL  3  MOUSE  BUTTONS  TO  EXIT."); 
closeobj(); 


/*  define  object  for  displaying  second  screen  of  operator  instructions  */ 


obj[SCREEN2j  =  genobjQ; 
makeobj(obj[SCREEN2]); 

color(BLUE);  /*  set  background  color  */ 

clear(); 

linewidth(lO); 

color  (RED); 

recti(0, 0,1023,767); 

linewidth(l); 

color(  WHITE); 

cmov2i(2 10,600); 

charstr("THE  FOG-M  PROGRAM  PROVIDES  A  SIMULATED  MISSILE  LAUNCH  AND"); 
cmov2i(210,575); 

charstr("OUT-THE- WINDOW  VIEW  OF  THE  TERRAIN  AS  SEEN  FROM  THE  OPERATOR’S"); 
cmov2i(210,550); 

charstr("CONSOLE  ON  THE  GROUND."); 
cmov2i(2 10,500); 

charstr("THE  GENERAL  AREA  FOR  THIS  FLIGHT  SIMULATION  IS  FT  HUNTER  LIGGETT"); 
cmov2i(210,475); 

charstrfCALIFORNIA  AND  VICINITY."); 
cmov2i(210,425); 

charstr("THE  SPECIFIC  TEST  AREA  IS  A  10  KILOMETER  REGION  DESIGNATED  BY"); 
cmov2i(210,400); 

charstr("UNIVERSAL  TRANSVERSE  MERCATOR  (UTM)  GRID  COORDINATES  10SFQ58."); 
cmov2i(300,100); 

charstr("PRESS  MIDDLE  MOUSE  BUTTON  TO  CONTINUE,"); 
cmov2i(305,85); 

charstr("OR  PRESS  ALL  3  MOUSE  BUTTONS  TO  EXIT."); 
closeobj(); 

/*  define  object  for  displaying  third  screen  of  operator  instructions  *  j 

obj[SCREEN3]  =  genobjQ; 
makeobj(obj|SCREEN3j); 

color(BLUE);  /*  set  background  color  * / 

dear  (); 

linewidth(lO); 

color(RED); 

recti(0,0, 1023,767); 

linewidth(l); 

color(  WHITE); 

cmov2i(385,650); 

chamr("PRE-LAl’NCH  ORIENTATION"); 
cmov2i(200,600); 

charstr("l.  WHEN  THE  PRE-LAUNCH  PHASE  OF  THE  FOG-M  SIMULATION  BEGINS,  A"); 
cmov2i(200,585); 

charstr("2-DIMENSIONAL  CONTOUR  MAP  OF  THE  TEST  AREA  (UTM  10SFQ58)  WILL  BE"); 
cmov2i(200,570); 

charstr("DISPLAYED  ON  THE  OPERATOR  CONSOLE.  TWO  CONTROL  PANELS  CONTAINING"); 
cmov2i(200,555); 

charstr("PRE-LAUNCH  INSTRUCTIONS  AND  CURRENT  LAUNCH  STATISTICS  WILL  ALSO"); 


cmov2i(200,540); 
charstr("BE  DISPLAYED."); 
cmov2i(200,490) ; 

ch*rstr("2.  THE  OPERATOR  WILL  BE  REQUIRED  TO  PROVIDE  TWO  CRITICAL  DATA"); 
cmov2i(200,475); 

charstr("ITEMS  TO  THE  LAUNCH  CONTROL  SYSTEM;  INITIAL  LAUNCH  POSITION  AND"); 
cmov2i(200,460); 

ch»ratr(  "TARGET  LOCATION."); 
cmov2i(200,410); 

charstr("S.  TO  DEFINE  INITIAL  LAUNCH  POSITION,  MOVE  CURSOR  OVER  DESIRED"); 
cmov2i(200,395) ; 

charstr("LOCATION  (REFER  TO  LAUNCH  STATISTICS  CONTROL  PANEL  TO  VIEW  THE"); 
cmov2i(200,380); 

charstr("CURRENT  UTM  GRID  COORDINATES).  PRESS  LEFT  MOUSE  BUTTON  TO  LOCK"); 
cmov2i(200,365); 

charstr("IN  LAUNCH  POSITION."); 
cmov2i(200,315); 

charstr("4.  TO  DEFINE  TARGET  LOCATION,  MOVE  CURSOR  OVER  DESIRED  LOCATION"); 
cmov2i(200,300); 

charstr(" (REFER  TO  LAUNCH  STATISTICS  CONTROL  PANEL  TO  VIEW  CURRENT  UTM"); 
cmov2i(200,285); 

ch&rstr("GRID  COORDINATES).  PRESS  RIGHT  MOUSE  BUTTON  TO  LOCK  IN  TARGET"); 
cmov2i(200,270); 

ch&rstrf'LOCATION.  THE  BLUE  LINE  DISPLAYS  THE  PROJECTED  FLIGHT  PATH.  THE"); 
cmov2i(200,255); 

charstr( "MISSILE  WILL  FLY  AT  A  CONSTANT  VELOCITY  AND  HEADING.  THE  LAUNCH"); 
cmov2i(200,240); 

ch<irstr(  "STATISTICS  CONTROL  PANEL  WILL  DISPLAY  COMPUTED  MISSILE  HEADING"); 
cmov2i(200,225); 

charstr("IN  DEGREES  (0  DEGREES  DUE  NORTH)."); 
cmov2i(240, 100) : 

ch&rstr(" PRESS  MIDDLE  MOUSE  BUTTON  TO  MOVE  INTO  PRE-LAUNCH  PHASE,"); 
cmov2i(326,85); 

charstr("OR  PRESS  ALL  3  MOUSE  BUTTONS  TO  EXIT."); 
closeobj(); 


MAKETANK 


#  include  "gl.h" 
^include  "fogm.h" 

maketank(item) 
Object  *item; 

{ 


long  points  =  4,  bigpoints  =  8; 
float  parrayj8j[3]; 
float  lx,ly,lz; 

long  cmin  =  MINTGTCOLOR,  cmax  =  MAX  TGT  COLOR,  cl; 

lx  =  400.0  *  41.01;  /*  direction  of  lightsource  */ 
ly  =  6000.0; 

Iz  =  200.0  *  (-41.01); 


*item=genobj(); 

makeobj(*item); 

/*  draw  right  side  of  tank  CCW  * / 

parray[0][0]  =  -10.0; 

parrayjojjlj  =  6.0; 

parray(0]j2]  =  -5.0; 

parrayjljjO]  =  -15.0; 

parray(lj|lj  =  4.0; 

parrayjl][2]  —  -5.0; 

parray[2](0)  =  -15.0; 

parray[2]jl)  =  2.0; 

parray[2|(2]  =  -5.0; 

parrayjsjjo]  =  -10.0; 

parray[3](lj  =  0.0; 

parrayjsj^j  =  -5.0; 

parray[4|(0j  =  10.0; 

parray[4][l)  =  0.0; 

parray[4|[2j  =  -5.0; 

parray^5lr0l  =  15.0: 

parray  5i  li  =  2.0: 

parray’5^2!  =  -5.0: 

parray[6||0]  =  15.0; 

parray[6][l]  =  4.0; 

parray[6|[2|  =  -5.0; 

parray[7]j0)  =  10.0; 

parray(7][  lj  =  6.0; 

parray|7](2j  =  -5.0; 

lightorient  (parray,  bigpoints,  0.0,0. 0,0.0,  lx,  ly.lz.cmin.cmax.&cl); 
color(cl); 
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polf(bigpoints,parray); 

/*  front  of  tank  CW  */ 
parray[0][0|  =  15.0; 
parray[0]jl]  =  5.0; 
parray[0j[2j  =  -5.0; 
parrayjljjoj  =  15.0; 
parrayjljjlj  =  S.0; 
parray[lj[2]  =  -5.0; 
parray[2|(0j  =  15.0; 
parray{2]|lj  =  S.O; 
parrayj2j[2]  =  5.0; 
parrayjsjjoj  =  15.0; 
parrayjsjjlj  =  5.0; 
parray[3]j2|  =  5.0; 

lightorient(parray,  points,  0.0, 0.0, 0.0,  lx,  ly,lz,cmin,cmax,&cl); 
color(cl); 

polf  (points.parray ) ; 

/*  draw  left  side  of  tank  CW  */ 
parray[0][0]  =  10.0; 
parrayjojjlj  =  6.0; 
parray[0|[2j  =  5.0; 
parrayjljjoj  =  15.0; 
parrayjljjlj  =  4.0; 
parray[lj[2j  =  5.0; 
parray[2|joj  =  15.0; 
parrayj2]jlj  =  2.0; 
parray[2][2j  =  5.0; 
parrayjsjjoj  =  10.0; 
parrayjsjjlj  =  0.0; 
parray(3j[2]  =  5.0; 
parrayj4jjoj  =  -10.0; 
parrayj4jjlj  =  0.0; 
parray|4jj2j  =  5.0; 
parray[5jjoj  =  -15.0; 
parrayjsjjlj  =  2.0; 
parrayjsj  j2j  =  5.0; 
parrayjejjo]  =  -15.0; 
parrayjojjlj  =  4.0; 
parrayjejj2j  =  5.0; 
pan-ay^HO!  =  -10.0: 
parr  ay  1 7!  1  i  =  6.0; 
parray'7 '2!  =  5.0: 

Iightorient(parray,bigpoints,0.0,0.0,0.0,lx,ly,lz,cmin,cmax,ikcl); 

color(cl); 

polf(bigpoints,parray); 

/*  back  of  tank  CCW  */ 
parray(0j(0j  =  -15.0; 
parrayjojjlj  =  4.0; 
parrayjojj2j  =  5.0; 
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parray[l][0]  =  -15.0; 
parrayjljjlj  =  2.0; 
parrayjl][2]  =  5.0; 
parray[2jjo|  =  -15.0; 
parray(2][l]  =  2.0; 
parray  [2]  [2]  =  -5.0; 
parrayjsjjo]  =  -15.0; 
parrayjsjjlj  =  4.0; 
parray(S](2j  =  -5.0; 

lightorient(parray, points, 0.0,0. 0,0.0, lx, ly, lx, cmin,cmax,&cl); 

color(cl); 

polf(  points, parray ) ; 

/*  top  middle  of  tank  body  CCW  */ 

parray[0][0]  =  -10.0; 

parrayjojjl]  =  6.0; 

parray[0jj2]  =  -5.0; 

parrayjljjo]  =  -10.0; 

parrayjljjlj  =  6.0; 

parray[l][2)  =  5.0; 

parray[2|[0j  =  10.0; 

parray[2][l]  =  6.0; 

parray[2|[2j  =  5.0; 

parray(3j[oj  =  10.0, 

parray(3]jl]  =  6.0; 

parray[3][2]  =  -5.0; 

lightorient  (parray,  points,  0.0, 0.0, 0.0,  lx,  ly,  Is,  cmin,cmax,&:cl); 
color(cl); 

po  If  (points,  parray )  ; 

/*  top  front  of  tank  body  CCW  */ 

parray[0j(0]  =  10.0; 

parray  joj[l)  =  6.0; 

parray[0j[2j  =  -5.0; 

parrayjljjoj  =  10.0; 

parrayfljjl]  =  6.0; 

parrayjljj2]  =  5.0; 

parrayj2jjo]  =  15.0; 

parrayj2jflj  =  4.0; 

parrayj2jj2]  =  5.0; 

parrayjsjjoj  -  15.0; 

parraviSHl'  =  4.0; 

parrayi3,.2'  = 

lightorient  I  parray.  poin  ts.i).  0.0. 0.0.0,  lx.  iy.lz. cm  in. cmax.Jkc  II: 
color(cl); 

polf(  points,  parray); 

/*  top  back  of  tank  body  CCW  */ 
parray[0](0j  =  - 10.0, 
parray  jo  j  f  1  j  =  6.0; 
parrayjojf2j  =  -5.0; 
p  array}  1](0]  =  -15.0; 
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parray[l][l]  =  4.0; 
parray[lj(2]  =  -5.0; 
p&rr&y[2|joj  =  -15.0; 
p«rr»y[2||lj  =  4.0; 
parray[2]j2j  =  5.0; 
parray  jsjjO]  =  -10.0; 
parrayjsjjlj  =  6.0; 
parray  jsjj2]  =  5.0; 

lightorient(parray,  points,  0.0, 0.0, 0.0,  lx,  ly,lz,cmin,cmax,&cl); 
color(cl); 

polf(  points, parray); 

/*  bottom  middle  of  tank  CW*/ 
parray  [0]  [0]  =  -10.0; 
parray  jojjlj  =  0.0; 
parray[0|[2]  =  -5.0; 
parray  [1]  [Oj  =  10.0; 
parrayjljjlj  =  0.0; 
parray|lj[2j  =  -5.0; 
parray[2][0]  =  10.0; 
parray[2)[l]  =  0.0; 
parray[2|[2]  =  5.0; 
parray(3l(0l  =  -10.0; 
parray[3|il|  =  0.0; 
parray[3j[2]  =  5.0; 

lightorient  (parray, points, 0.0,0. 0,0. 0,lx,ly,lz,cmin,cmax,&cl); 
color(cl); 

polf  ( points ,  parray ) ; 

j*  bottom  front  of  tank  CW  */ 
parray  (0)  [Oj  =  10.0; 
parray  [0]  1 1]  =  0.0; 
parrayjoj[2|  =  -5.0; 
parrayjljjo]  =  15.0; 
parrayjljjlj  =  2.0; 
parray[l](2]  =  -5.0; 
parray(2j[0]  =  15.0; 
parrayj2|(lj  =  2.0; 
pairay(2j[2|  =  5.0; 
parray  j3j[0]  =  10.0; 
parray(3|[lj  =  0.0; 
parray'3-2!  =  5.0: 

lightonenM  parray. points. 0.0. 0.0. 0.0. lx. ly.lz.cmm.cmax.ifcc  1 ); 
color(cl); 

polf(  points,  parray); 

J*  bottom  back  of  tank  CW  */ 
parray  JO]  |0]  =  -10.0; 
parrayJOjjl]  =  0.0; 
parray  (0][2j  =  -5.0; 
parrayjljjo]  =  -10.0; 

parrayjljjlj  =  0.0; 


parray[lj[2]  =  5.0; 
p&rra.y[2][0}  =  -15.0; 
parray[2][l]  =  2.0; 
parrayj2][2]  =  5.0; 
parray[3][0]  =  -15.0; 
parrayjsjjl]  =  2.0; 
parray[sj(2]  =  -5.0; 

lightorient(parray)point3I0.0,0.0,0.0,lx,ly,li1cmin,cmax1lccl); 

color(cl); 

polf(points,parray); 

/*  right  side  of  gun  barrel  */ 
parray[0][0j  =  1.6667; 
parrayjojjlj  =  8.0; 
parray[0][2]  =  -0.5; 
parrayjljjoj  =  2.3333; 
parrayjljjlj  =  7.0; 
parray(lj[2|  =  -0.5; 
parray[2][0j  =  17.0; 
parray[2|[l]  =  7.0; 
parray[2|[2]  =  -0.5; 
parrayjsjjoj  =  17.0; 
parray[3][lj  =  8.0; 
parTayj3|[2j  =  -0.5; 

lightorient(parray, points, 5. O^.S.O.O.lx.ly.lz^min.cmax.&cl); 
color(cl); 

polf(points,parray); 

/*  top  of  gun  barrel  */ 
parray[0][0]  =  1.6667; 
parrayjojjl]  =  8.0; 
parrayjojj2j  =  0.5; 
parrayjljjoj  =  1.6667; 
parrayjljjlj  =  8.0; 
parray[l][2]  =  -0.5; 
parrayj2]joj  =  17.0; 
parrayj2jjlj  =  8.0; 
parrayj2]j2j  =  -0.5; 
parrayjsjjoj  =  17.0; 
parrayjsjjlj  =  8.0; 
parray[3][2]  =  0.5; 

lightorient(parray,points,5.0.2.5.0.0.lx,ly.lz,cmin.cmax.  Accl); 

colorfc  l ); 

polf(points.parray): 

/*  left  side  of  gun  barrel  */ 
parray(0](0]  =  17.0; 
parrayjojjl  j  =  8.0; 
parrayjojj2j  =  0.5; 
parrayjljjoj  =  17.0; 
parrayjljjlj  =  7.0; 
parrayj  1]  [2]  =  0.5; 


parray[2][0]  =  2.3333; 
parray|2][l]  =  7.0; 
parray[2j[2]  =  0.5; 
parray[3][0)  =  1.6667; 
parrayjSjjlj  =  8.0; 
parrayjsjj2j  =  0.5; 

lightorient(parray,  points,  5.0,2.5, 0.0,  lx,  ly,lz,cmin,cmax,4tcl); 
color(cl); 

polf (points,  parray )  ; 

/*  end  of  gun  barrel  */ 
parray  [0)[0]  =  17.0; 
parray  jojjlj  =  8.0; 
parray[0j[2j  =  -0.5; 
parrayjljjo]  =  17.0; 
parrayjljjlj  =  7.0; 
parray(l|[2]  =  -0.5; 
parray  [2]  [0)  =  17.0; 
parray[2][l|  =  7.0; 
parrayj2j[2j  =  0-5; 
parray  [3]  [0]  =  17.0; 
parrayjsjjl]  =  8.0; 
parray(3|[2]  =  0.5; 

lightorient(parray, points, 5. 0,2.5, 0.0, lx,  ly,lz,cmin,cmax,&:cl); 
color(cl); 

polf(  points, parray); 

/“bottom  of  gun  barrel  */ 
parray  [0][0]  =  2.3333; 
parrayjojfl]  =  7.0; 
parray  [0]  [2]  =  0.5; 
parrayjljjo]  =  2.3333; 
parrayjljjlj  =  7.0; 
parray[lj[2)  =  -0.5; 
pairay[2](0)  =  17.0; 
parray[2][l]  =  7.0; 
parray[2][2j  =  -0.5; 
parrayjsjjoj  =  17-0; 
parray[3|[l|  =  7.0; 
parray[3][2]  =  0.5; 

lightorient  (parray, points, 5.0, 2.5,0. 0, lx, ly,lz,cmin,cmax,j£el); 
color(cl); 

po  lf(  points,  parray ); 

/*  right  side  of  turret  */ 
parray  [0|  [0]  =  -3.0; 
p  array  jojjl]  =  9.0; 
parray[0j[2]  =  -1.0; 
parrayjljjoj  =  -5.0; 
parrayjljjlj  =  6.0; 
parray  j  1  j  [2[  =  -3.0; 
parray  (2jjo|  =  3.0; 


parray{2)[l|  =  6.0; 
parray[2j(2]  =  -3.0; 
parray  [3]  [0]  =  1.0; 
parrayislll]  =  9.0; 
pairay(3][2]  =  -1.0; 

lightorient(parray,  points, -1.0, 2.5, 0.0,  lx,  ly,lz,cmin,cmax,&cl); 
color  (cl); 

polf(points,parray); 

/*  front  side  of  turret  */ 
parray[0][0]  =  1.6667; 
parrayjojjlj  =  9.0; 
parray[0](2]  =  -1.0; 
parrayjlj[0]  =  3.0; 
parray[l][l]  =  6.0; 
parrayjlj[2]  =  -3.0; 
parray  [2]  [0]  =  3.0; 
parray(2][ll  =  6.0; 
p&rray[2j(2]  =  3.0; 
parray(3][0j  =  1.6667; 
parray[3][l]  =  9.0; 
parray[S](2j  =  1.0; 

lightorient(parray  .points, -1.0,2. 5. 0.0,lx.ly,lz,cmin,cmax.3icl); 
color(cl); 

polf(points,parray); 

/*  left  side  of  turret  * / 
parrayj0]j0j  =  1.6667; 
parrayjoj[l|  =  9.0; 
pairay[0)[2]  =  1.0; 
parray[lj[0]  =  3.0; 
parray|l](l]  =  6.0; 
parray|l][2]  =  3.0; 
parray(2)[0)  =  -5.0; 
parray|2|[l]  =  6.0; 
parray[2](2]  =  3.0; 
p»»ray[3](oj  =  -3.0; 
parrayjsjjl]  =  9.0; 
parray[3j(2j  =  1.0; 

lightorient(parray,points,-1.0,2.5,0.0,bc,ly,lz,cmin,cmax,&cl); 

color(cl); 

polff  points. parray); 

*  back  side  of  turret  * 
parray  j0](0]  =  -3.0; 
parray  [0)[1]  =  9.0; 
parray[0][2]  =  1.0; 
parrayjljjoj  =  -5.0; 
parrayjljjl]  =  6.0; 
parrayjl]j2]  =  3.0; 
parray(2j(oj  =  -5.0; 
parray  [2]  j  lj  =  6.0; 


P4rr*y[2j|2j  =  -SO; 
p*rr»y[aj[0]  =  -S.O; 

P*rr»y[sjilj  =  9.0; 

P4ir»yisj[2|  =  -1.0; 

lightorient(parray,points,-1.0,2.5,0.0,lx,ly,ls,cmin,cinax,4tcl); 

color(el); 

polf(points.parray); 

/•  top  of  turret  */ 
pMTny[0|(0]  =  -S.O; 
parray[0]|l]  =  9.0; 
panray[oj[2)  =  1.0; 
parrayjljjo]  =  -S.O; 
p«jTay[lj(lj  =  9.0; 
parrnyjlj|2|  =  -1.0; 
purray[2|(oj  =  1.0; 
parrayj2|jlj  =  9.0; 
parray(2|[2|  =  -1.0; 
parrayj3l[0j  =  1.0; 
parray[3j[l]  =  9.0; 
parray[3j(2j  =  1.0; 

lightorient(parray,  points, -1.0, 2.5, 0.0,  lx,  ly,li,cmin,cmax,lccl); 
color  (cl); 

polf(points,  parray ) ; 


closeobj(); 


NEAREST  TGT 


# include  "gl.h" 

#  include  "fogm-h" 

neareat_tgt(vx,vy,ve,px,py,p»,tgt_idx) 

Coord  vx,  vy,  v«,  px,  py,  pa; 
int  *tgt_idx; 

{ 

float  diet,  diat_to_los(); 
float  min  diat; 
float  num_tgts; 

extern  float  tgt_poa(MAX_TGTSj(3|; 
int  index; 

numtgta  =  10; 

mindiat  =  dist_to_los(vx,vy,v*,px,py,pi,ictgt_pos[0][0|); 
*tgt_idx  =  0; 

for  (index  =  1;  index  <  num_tgta;  +4- index)  { 

diat  =  diat_to_loa(vx,vy1vi,px,py,p*1i£tgt_pos[index)jO]) 
if  (diat  <  min  diat)  { 
mindiat  =  diat; 

*tgt_idx  =  index; 


NPOLY  ORIENT 


/*  npoly_orient.c  */ 

£  include  <gl.h> 

^include  <math.h> 

int  npoly  orient(ncoords,xys,xinside,yinside, sinside) 
unsigned  int  ncoords; 

Coord  xys[](S); 

Coord  xinside,  yinside,  sinside; 

{ 


register  unsigned  short  int  ij;  /*  loop  temps  */ 

Coord  center(S);  /*  center  coordinate  of  the  polygon  */ 

Coord  a{3),  bjSj;  /*  vector  hold  locations  for  the  vectors  that  run 
from  the  center  coordinate  to  the  points  of  the 
polygon  */ 

Coord  xnlS],  xmnfSj;  /*  points  on  line  containing  normal  that  are 
on  opposite  sides  of  the  plane  containing 
the  polygon. 

7 

float  distton;  /*  distance  to  point  n  from  pt  inside.  */ 
float  disttomn;  j*  distance  to  point  -n  from  pt  inside.  */ 

Coord  normal[3|;  /*  the  normal  vector  computed  from  a  x  b  */ 


/*  compute  the  center  coordinate  of  the  polygon  */ 
center(Oj  =  0.0; 
center)  1]  =  0.0; 
center(2j  =  0.0; 

for(i=0;  i  <  ncoords;  i++) 

{ 

for(j=0;  j  <  3:  j++) 

I 

l 

centerijj  -=  xyziiiijj; 

} 

} 

/*  divide  out  by  the  number  of  coordinates  */ 
for(j=0;  j  <  3;  j++) 

{ 

centerjjj  =  center[j)/(float)ncoords; 

} 
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/*  check  the  first  2  coordinates  of  the  polygon  for  their  direction  */ 


/*  compute  vector  a.  It  runs  from  the  center  coordinate  to  coordinate  0  */ 
for(j=0;  j  <  3;  j++) 

{ 

Mil  =  *y*[0]ij!  -  center  [j]; 

} 

/*  compute  vector  b.  It  runs  from  the  center  coordinate  to  coordinate  1  *  j 
for(j=0;  j  <3;  j++) 

{ 

Mi]  =  xy*U]li]  -  centerjj]; 

} 

/*  compute  a  x  b  to  get  the  normal  vector  *  j 
normal [0]  =  a(l]*b[2]  -  a(2]*b[l]; 
normal]  l]  =  a(2]*b[0]  -  a(0]*b(2|; 
normal[2]  =  a[0]*b(l]  -  a(l]*b[0|; 

/*  compute  point  n,  offset  pt  from  center  in  direction  of  normal  */ 
for(j=0;  j  <  3;  j++) 

{ 

xnlj]  =  center[j|  +  normal[j]; 

} 

/*  compute  point  -n,  offset  pt  from  center  in  opposite  direction 
from  normal. 

V 

foT(j=0-,  j  <  3;  j++) 

{ 

xmn[j]  =  centerjj]  -  normal[j|; 

} 

/*  compute  the  distance  the  inside  pt  is  from  point  n  */ 
distton  =  sqrt((xn[0j  -  xinside)  *  (xn[0j  -  xinside)  + 

(xn[l|  -  yinside)  *  (xn[l]  -  yinside)  + 

(xn[2]  -  sinside)  *  (xn[2)  -  xinside) ) ; 

/*  compute  the  distance  the  inside  pt  is  from  point  -n  */ 
disttomn  =  sqrt((xmn[0|  -  xinside)  *  (xmn[0j  -  xinside)  + 

(xmn(l)  -  yinside)  *  (xmn(lj  -  yinside)  + 
fxmn i'2i  -  zinside)  *  (xmni2l  -  zinside)); 


PRELAUNCH 


/*  The  function  prelaunch  is  the  user  interface  portion  of  the  FOG-M 
flight  simulation.  It  allows  the  operator  to  interactively  enter 
critical  data  items  necessary  to  simulate  the  missile  in  flight. 

The  function  returns  the  initial  launch  position  in  the  x-i  plane 
and  also  the  direction  of  flight.  */ 

#include  "gl.h" 

#include  "device. h" 

#include  "fogm.h" 

#include  "math.h" 

prelaunch(vx,  vy,  vs,  direction,  compassdir,  active,  obj,  tag) 

Coord  *vx,  *vy,  *vz; 
double  ‘direction; 
float  ‘compassdir; 
int  ‘active; 

Object  obj(7j; 

Tag  tag[6l; 

{ 

float  gnd_level(); 
float  compassf); 

int  screencnt,  launchlock,  targetlock; 

int  xval,  yval,  xlaunch,  ylaunch,  xtarget,  ytarget,  utm  x,  utm  y; 
char  xtemp(35],  ytempjSSj,  dist(35),  heading(35); 
float  distance; 

double  xdistance,  ydistance; 

Colorindex  unmask; 

xtemp[0]  =  ’  ’; 
ytempjO]  =  ’  ’; 
dist [0]  =  ’  ’; 
heading[0|  =  ’  ’; 

unmask  =  (l<<getplanes())  -1; 

writemask(  unmask); 

if  (TV)  viewport(0, 835. 0,474); 

"Ise  view  port  1 0.1023, 0.787): 
pushmamxl ): 

onho2(0.0, 1023.0, 0.0, 767.0); 

‘direction  =  0.0;  /*  initialize  the  direction  */ 


cursoffQ;  /*  turn  the  cursor  off  */ 

callobj(obj(SCREENl]);  /*  display  screen  1  */ 

swapbuffers(); 


scre«ncnt  =  1;  /*  initialise  counter  for  screen  displays  */ 

while(TRUE)  { 

frontbuffer(TRUE) ; 

if  (getbutton(MOUSE2)  kk  '.(getbutton(MOUSEl))  kk  !(getbutton(MOUSE3)))  { 
ringbellQ; 

while  (getbutton(MOUSE2)); 
screencnt  +=  1; 

if  (screencnt  ==  2)  callobj(obj[SCREEN2j); 
else  if  (screencnt  ==  3)  callobj(obj|SCREEN3]); 

else  break; 

} 

if  (getbutton(MOUSEl)  kk  (getbutton(MOUSE2))  kk  (getbutton(MOUSES)))  { 
‘active  =  FALSE; 
goto  exit; 

} 

} 

frontbuffer(FALSE); 

editobj(obj[FLTPATHj);  /*  erase  previous  missile  path  */ 

objreplace(tagjMISSILEj); 

circf(0.0,  0.0,  0.0); 

move2(0.0,  0.0); 

draw2(0.0,  0.0); 

objreplace(tag[TGT|); 

circf(0.0,  0.0,  0.0); 

closeobj(); 

editobj(obj|STATS]);  /*  erase  previous  launch  statistics  */ 

objrepiace(tag(HEAD|); 

charstr(""); 

cmov2i(115,60); 

charstr(""); 

objreplace(tag[TARGET]); 

charstrC’"); 

cmov2i(0,0); 

charstr(""); 

closeobj(); 

setcursor(0, RED, unmask);  /*  set  up  cursor  and  mouse  */ 

attachcursor(MOUSEX, MOUSEY); 
set  valuatorlMOUSEX.  384. 0.767); 

■>et valuator |  MOUSEY. 384. 0.767); 
urson( ): 

launchlock  =  FALSE; 
targetlock  =  FALSE; 

callobj(objjCONTOURj);  /*  load  static  displays  into  both  buffers  */ 
callobj(objjlNSTRl); 

callobj(objjSTATS));  /*  included  so  swapped  buffer  doesn’t  have  "hole"  */ 
swapbuffers(); 
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callobj(obj(CONTOUR]); 

callobj(obj[INSTR]); 

while(TRUE)  { 

if  (getbutton(MOUSEl)  kk  (getbutton(M0USE2))  kk  (getbutton(MOUSE3)))  { 
’active  =  FALSE; 
goto  exit; 

} 

xval  =  getvaluator(MOUSEX);  /*  read  the  x  and  y  mouse  positions  */ 

yval  =  getvaluator(MOUSEY); 

utm_x  =  (50000  +  (int)(xval  *  GRID_FACTOR));  /*  compute  grid  coordinates  */ 

utm_y  =  (80000  +  (int)jyval  *  GRID  FACTOR)); 

sprintf(xtemp,"%4dM,utm_x);  /*  store  coordinates  in  temporary  buffer  */ 

sprintf(ytemp,"%4d",utm_y); 

/*  if  LEFT  MOUSE  selected  lock  in  launch  position  and  update  control  panel  *. 

if  (getbutton(MOUSE3)  kk  (!getbutton(MOUSE2))  kk  (Igetbutton(MOUSEl)))  { 
ringbell(); 
xlauAch  =  xval: 
ylaunch  =  yval; 
launchlock  =  TRUE; 

*vx  =  ((float)((xval  *  FT_10K)/767)); 

*vz  =  -((float)((yval  *  FT_10K)/767)); 

*vy  =  gnd_level(*vx,  *vz)  +  200.0; 

editobj(obj(STATSl); 

objreplace(tag(LAUNCH]); 

charstr(xtemp); 

cmov2i(170,220); 

charstr(ytemp); 

closeobj(); 

}  /*  end  of  MOUSE3  hit  */ 

j*  As  long  as  LEFT  MOUSE  not  selected,  keep  on  displaying  current  UTM 
grid  coordinates  in  control  panel  area.  */ 

if  (llaunchlock)  { 

editobj(obj  [STATS]); 
objreplace(tag'LAUNCHl): 

■harstrlxtempi: 
cmov2i(  170.220); 
charstr(ytemp); 
closeobj(); 

} 

/*  if  RIGHT  MOUSE  selected  lock  in  target  and  update  control  panel.  */ 

if  (getbutton(MOUSEl)  kk  (!getbutton(MOUSE3) )  kk  (!getbutton(MOUSE2)))  { 
ringbellf); 
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xtarget  =  xval; 

ytarget  =  yval; 

target  lock  =  TRUE; 

editobj  (obj(ST  ATS)); 

objreplace(iag)TARGETj); 

charstr(xtemp); 

cmov2i(l70,140); 

charstr(ytemp); 

closeobjQ; 

} 

/*  As  long  as  RIGHT  MOUSE  not  selected  keep  on  displaying  current  UTM 
grid  coordinates  in  control  panel  area.  */ 

if  (Itargetlock)  { 

if  (launchlock)  { 

xdistance  =  ((double) (xval  -  xlaunch)); 
ydistance  =  ((double)(yval  -  ylaunch)); 

distance  =  sqrt( (float) (xdistance  *  xdistance  +  ydistance  *  ydistance)); 
distance  =  distance  *  GRID  F ACTOR; 
sprintf(dist,"%5.0f  METERS",  distance); 

‘direction  =  atan2(ydistance,  xdistance); 
if  (‘direction  <  0.0)  ‘direction  +=  TWOPI; 

‘compassdir  =  compass(*direction); 

sprintf(heading,"%d  DEGREES",  (int)* compassdir); 

editobj  (obj  [ST  ATS  j ) ; 

objreplace(tag[TARGET|); 

charstr(xtemp); 

cmov2i(170,140); 

charstr(ytemp); 

objreplace(tag[HEAD|); 

charstr  (heading); 

cmov2i(l  15,60); 

charstr(dist); 

closeobj(); 

} 

} 

/*  if  launch  position  and  target  location  have  been  selected  by  the 

operator  compute  the  direction  of  the  missile  and  distance  to  target.  */ 

if  (launchlock  &&  targetlock)  { 

xdistance  -  ((double)(xtarget  -  xlaunch)); 
ydistance  =  ((doubiej(ytarger.  -  ylaunch)); 
distance  =  sqrt((float)((xdistance  *  xdistance)  * 

(ydistance  *  ydistance))); 
distance  =  distance  *  GRID  _F ACTOR; 
sprintf(dist,"%5.0f  METERS",  distance); 

‘direction  =  atan2(ydistance,  xdistance); 
if  (‘direction  <  0.0)  ‘direction  +=  TWOPI; 

‘compassdir  =  compass(*direction); 


sprintf(heading,"%d  DEGREES",  (int)*compassdir); 

editobj  (obj  (ST  ATS  j ) ; 

objreplace(tag(HEADj); 

charstr(heading); 

cmov2i(  115,60); 

charstr(dist); 

closeobj(); 

} 

/*  add  small  red  and  blue  circles  to  contour  map  to  indicate  launch 
position  and  target  location.  Connect  circles  to  indicate  missile 
flight  path  */ 

if  (launchlock) 

if  (targetlock)  { 

editobj(obj(FLTPATH]); 

objreplace(tag[MISSILEj); 

circf(  (float  )(xlaunch)/767.0*  100.0,  (float)(ylaunch)/767.0*100.0,  0.6); 
move2((float)(xtarget)/767. 0*100.0,  (float)(ytarget)/767. 0*100.0); 
draw2((float)(xlaunch)/767.0*  100.0,  (float)  (ylaunch)/767. 0*100.0); 
objreplace(tag(TGTj); 

circf( (float )(xtarget)/767.0*  100.0,  (float)(ytarget)/767.0*100.0,  0.6); 
closeobj(); 

} 

ebe  { 

editobj(obj[FLTPATH|); 

objreplace(tag[MISSILE|); 

circf((float)(xlaunch)/767.0*100.0,  (float) (ylaunch)/767.0*100.0,  0.6); 
move2( (float) (xval)/767.0*  100.0,  (float)(yval)/767.0*100.0); 
draw2((float)(xlaunch)/767.0*  100.0,  (float) (ylaunch)/767.0*  100.0); 
closeobjQ; 

} 

/*  if  MIDDLE  MOUSE  selected,  launch  has  occurred  and  control  transfers 
back  to  main  portion  of  FOG-M  program  displaying  out-the-window  3-D 
view  of  the  flight  area.  */ 

if  (getbutton(MOUSE2)  bit.  (!getbutton(MOUSEl))  Stic  (!getbutton(MOUSE3)) 
bit  launchlock  bb  targetlock)  { 
ringbellQ; 

while  (getbutton(MOUSE2)); 
break; 
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writemask(SAVEMAP); 

c«Uobj(obj[FLTPATH]) 

writemask  (unmask); 
caUobj(obj  [STATS]); 
swapbuffersQ; 


cursoffQ; 

popmatrix(); 
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RANDNUM 


/*  rajidnum.c  -  returns  a  random  float  between  sero  and  one  */ 

static  long  seed  =  1234567; 

r  andseed  ( newseed ) 
long  newseed; 

{ 

seed  =  newseed; 

} 


float  randnumQ 

{ 

long  multQ; 

seed  =  (mult(seed, 31415821)  +  1)  %  100000000; 
return  (seed  /  100000000.0); 

} 

long  mult(p.q) 
long  p,q; 

{ 

long  pO,  pi,  qO,  ql; 

pi  =  p  /  10000; 
pO  =  p  %  10000; 
ql  =  q  /  10000; 
qO  =  q  %  10000; 

return((((p0*ql  +  pl*q0)  %  10000)  *  10000  +  p0*q0)  %  100000000); 

} 
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READCONTROLS 


/*  reads  the  values  from  the  operator’s  controls  (mouse  and  dials)  */ 


#  include  "gl.h" 
^include  "fogm.h" 

#  include  "device. h" 


/*  graphics  lib  defs  */ 

/*  fogm  constants  */ 
/*  device  definitions  */ 


read_controls(designate,  greyscale,  flying,  active,  speed,  direction, 
compassdir,  alt,  pan,  tilt,  fovy) 


int  ‘designate,  ‘greyscale,  ‘flying,  ‘active,  ‘fovy; 
float  ‘speed,  ‘compassdir; 
double  ‘direction,  ‘pan,  ‘tilt; 

Coord  ‘alt; 


extern  float  randx,  randy,  randz; 
float  randnumQ; 

Colorindex  colors)  1]; 


/*  quit  if  all  three  mouse  buttons  are  pushed  */ 

if(getbutton(MOUSEl)  kk  getbutton(MOUSE2)  kk  getbutton(MOUSES))  { 
‘flying  =  FALSE; 

‘active  =  FALSE; 

} 

else  { 

if  (getbutton(MOUSE3)  kk  !(getbutton(MOUSE2)))  {  /*  Zoom  In  */ 

‘fovy  =  (‘fovy  <  (80  +  DELTAFOVY))  ?  80  :  ‘fovy  -  DELTAFOVY; 

} 


if  (getbutton(MOUSEl)  kk  !(getbutton(MOUSE2)))  {  /*  Zoom  Out  */ 

‘fovy  =  (‘fovy  >  (550  -  DELTAFOVY))  ?  550  :  ‘fovy  +  DELTAFOVY; 

} 


if  (getbutton(MOUSE2))  {  /*  designate/reject  target  */ 

if  (‘designate)  {  /*  see  if  target  in  sights  */ 

/‘pushmatrixQ; 

pushviewport(); 
pushattributesQ; 
viewport(0.  1023.  0.  767); 
ortho2(0.0,  1023.0,  0.0.  767.0); 

<:mov2s((Scoord)(768, 2).  (S'coord)(768/  2)); 
readpixels(  1 , colors ) ; 

if  ((colors|0|  >=  MINTGTCOLOR)  kk  (colors[0|  <=  MAX  TGT  COLOR))  {*/ 
‘designate  =  FALSE; 
ringbell(); 

randx  =  30.0  *  randnum()  -  15.0; 
randy  =  10.0  *  randnum()  -  5.0; 
randz  =  10.0  *  randnumQ; 
while  (getbutton(MOUSE2)); 
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/*} 

popattributesQ; 
popviewport(); 
popmatrix();  */ 

} 

else  {  /*  reject  currently  designated  target  */ 

ringbellQ; 

‘designate  =  TRUE; 

/*  re-adjust  tilt  and  pan  values  appropriately  */  ; 

} 

} 

if  (‘greyscale  !=  getvaluator(DIALS))  {  /*  DIALS  indicates  color  change  */ 
‘greyscale  =  !*greyscale; 
setvaluator(DIAL3,  ‘grey  sc  ale, 0,1)  > 
colorramp(*grey  sc  ale, FALSE); 

} 

‘speed  =  (float) (getvaluator(DIAL2)  /  SPEEDSENS);  /*  get  desired  speed  */ 
‘alt  =  (Coord)(getvaluator(DIAL4)j; 

‘pan  =  DTOR  *  (double)(-getvaluator(MOUSEX))  /  PANSENS; 

‘tilt  =  DTOR  *  (double) (getvaluator(MOUSEY))  /  TILTSENS: 

‘compassdir  =  (float)getvaluator(DlALO)  /  DIRSENS; 

/*  keep  ‘direction  between  0  and  300,  update  valuator  if  changed  */ 
if  (‘compassdir  >=  360.0)  { 

‘compassdir  -=  360.0; 

setvaluator(DIALO,(int)(*compassdir*DIRSENS),  (int)(-360*DIRSENS), 
(int)(720*DIRSENS)); 

} 

if  (‘compassdir  <  0.0)  { 

‘compassdir  +=  380.0; 

setvaluator(DIALO,(int)(*compassdir*DIRSENS),  (int)(-360*DIRSENS), 
(int)(720*DIRSENS)); 

} 


/‘convert  ‘direction  from  compass  degrees  to  trigonometric  radians  */ 
‘direction  =  (‘compassdir  <=  90.0)  ?  DTOR  *  (90.0  -  ‘compassdir)  : 
DTOR  *  (450.0  -  ‘compassdir); 


READ DATA 


/*  reads  the  raw  16  bit  elevation  and  vegetation  code  data 
from  the  DMA  data  file  and  inserts  it  into  the  global 
gridpixel  array  */ 

^include  "fogm.h" 

#  include  "files. h" 

readdataQ 

{ 

int  fd;  /*  file  descriptor  for  the  data  file  */ 

short  row,  col,  rowoffset,  coloffset;  /*  loop  indicies  */ 

extern  short  gridpixel[lOO][lOOj;  /*  DMA  elev  and  veg.  data  */ 


/*  read  the  data  from  the  data  file  into  the  gridpixel  array  */ 

fd  =  open(TERRAlN_FILE,RD); 

lseek(fd,0,0); 

for  (coloffset  =  0;  coloffset  <  NUMXGRIDS  *  10;  coloffset  +=  10)  { 

for  (rowoffset  =  0;  rowoffset  <  N"UMZGRIDS*10;  rowoffset  +=  10)  { 
for  (col  =  0;  col  <  10;  i-col)  { 

for  (row  =  0;  row  <  10;  -*-+row)  { 

read(fd,&gridpixel(rowoffset-t- rowj  [coloffset +col],  2); 


ROAD  BOUNDS 


finclude  "math.h" 

#include  "fogm.h" 

fdefine  X  0 
#define  Y  1 
fdefine  Z  2 

^define  NONE  0 

road  bounds(ptl,  pt2,  pt3,  road_width,  left_ptl,  right_ptl,  left_pt2, 
right  pt2,  firstxgrid,  first*  grid,  last_xgrid,  last  _*  grid) 

float  ptl[3|,  pt2[S|,  pt3[3],  roadwidth; 

float  left_ptl(3],  right_ptl[3],  left_pt2[3|,  right_pt2[3j; 

int  *first_xgrid,  "last  jtgrid,  *first_zgrid,  *last_2grid; 

{ 

float  deltax,  delta  *,  segdir,  min  x,  maxx,  min  *,  max  z; 
float  leftendljS),  right_endl[3],  left  start 2 [3],  right_start2[3], 
left_end2(3],  right_end2|3]; 
int  intersection  type; 

/*  determine  the  corner  points  of  the  segment  */ 

delta  x  =  pt2[X]  -  ptl[X|; 

delta  s  =  pt2[Z]  -  ptl(Z); 

seg  dir  =  atan2(delta_*,  delta  x); 

left_endl[X]  =  pt2(X]  +  (cos(seg_dir  +  HALFPI)*road_width/2.0); 
right_endl[X]  =  pt2(X]  +  (cos(seg_dir  -  HALFPI)*road_width/2.0); 
left_endl(Z|  =  pt2[Z]  +  (sin(seg_dir  +  HALFPI)*road_width/2.0); 
right_endl[Z)  =  pt2|Z)  +  (sin(seg_dir  -  HALFPI)*road_width/2.0); 

if  ((pt2[X|  !=  pt3[X))  ||  (Pt2|Z|  !=  pt3[Z|))  { 

/*  we  are  not  working  with  the  final  segment  of  this  road,  find 
the  intersection  of  this  segment  with  the  next  one  */ 
delta  x  =  pt3|X]  -  pt2(X|; 
delta_x  =  pt3(Z|  -  pt2[Z); 
seg  dir  =  atan2(delta_s,  delta  x); 

left_start2[X|  =  pt2[X]  +  (cos(seg_dir  +  HALFPI)*road_width/2.0); 
right_start2[X]  =  pt2[X|  +  (cos(seg_dir  -  HALFPI)*road_width/2.0); 
left  start2  Z1  =  pt2  Z!  -4-  (sin(seg_dir  4-  HALFPI)*road_width/2.0); 
right  start  2!  Z'  =  pt2;Zf  -  (sinjseg  _ iir  -  HALFPl)*road  width/ 2.0); 
left  <»n<i2lX!  =  ptSlX  *■  (cos(seg  dir  -  HALFPI)*road  width;  2.0); 
right  end2[Xj  =  pt3[X,  +  (cos(seg_dir  -  HALFPI)*road_width/ 2.0); 
left_end2[Z|  =  pt3|Z|  +  (sin(seg_dir  +  HALFPI)*road_width/2.0); 
right_end2(Z]  =  pt3(Z|  +  (sin(seg_dir  -  HALFPl)*road_width/2.0); 

/*  find  the  intersection  point  of  the  left  hand  sides  of  the 
first  and  second  road  segments  */ 
line_intersect2(left_ptl,  left  endl,  left_start2,  left_end2, 
left  pt2,  ^intersection  type); 


if  (intersection_type  ==  NONE)  { 
left  pt2[X]  =  left_endl(Xj; 
left_pt2[Z]  =  left_endl(Zj; 

} 

/*  find  the  intersection  point  of  the  right  hand  sides  of  the 
first  and  second  road  segments  */ 
line_intersect2(right_ptl,  right_endl,  right_start2,  right_end2, 
right_pt2,  &intersection_type); 
if  (intersection_type  ==  NONE)  { 
right_pt2[X]  =  right_endl[X]; 
right_pt2[Z]  =  right_endl[Zj; 

} 

} 

else  { 

/*  this  is  the  final  segment  of  this  road  * / 
left_pt2(X)  =  left_endl[X|; 
left_pt2[Z]  =  leftendl(Z); 
right_pt2[Xj  •=  right_endl[X|; 
right_pt2|Z|  =  rightendljZj; 

} 

/*  determine  the  min  and  max  x  and  z  values  */ 

minx  =  left_ptl[Xj; 

maxx  =  Ieft_ptl[X|; 

minx  =  left  _pt  1  [  Z  | ; 

max  i  =  left_ptl[Z]; 

if  (right  ptljX]  <  min  x)  min  x  =  right  ptl[Xj; 
if  (right_ptl[X]  >  max  x)  max  x  =  right_pt  1  [X] ; 
if  (right_ptl[Z|  <  min  i)  min  i  =  right _pt  1  [ZJ ; 
if  (right_ptl[Z)  >  max  x)  max  x  =  right_ptl[Zj; 
if  (left_pt2[X|  <  min  x)  min  x  =  left _pt2 [X] ; 
if  (left_pt2[X]  >  max  x)  max  x  =  left_pt2(Xj; 
if  (left_pt2[Z]  <  min  i)  min  x  =  left_pt2(Z|; 
if  (left_pt2(Z)  >  max  i)  max  z  =  left_pt2(Z|; 
if  (right_pt2(X]  <  min  x)  min  x  =  right_pt2[X]; 
if  (right_pt2[X)  >  max  x)  max  x  =  right_pt2[X|; 
if  (right_pt2[Z|  <  min  x)  min  x  =  right_pt2[Z); 
if  (right_pt2(Z|  >  max  x)  max  x  =  right_pt2[Zj; 

*first_xgrid  -  (int)(min_x/FT_100M); 

‘firstxgrid  =  (int)(min_x/FT_100M); 

‘last  xgrid  =  (int)(max_x/FT_100M); 

“last  xgnd  -  ( int)(max  ii  FT  100M); 
if  (‘first  xgnd  0)  ‘first  xgrid  =  0: 

if  ( ‘first  zgrid  <  0)  ‘first  xgrid  =  0; 

if  (‘last  xgrid  >  98)  ‘last  xgrid  =  98; 

if  (‘last  xgrid  >  98)  ‘last  xgrid  =  98; 
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SORT  ARRAY 


sort  array  (array,  numentries,  decending,  test_index) 
float  array(lOj[Si; 

int  num  entries,  decending,  test_index; 

{ 

int  ij; 

float  temp[3j; 

for  (i  =  0;  i  <  num  entries;  ++i)  { 

for  (j  =  i  +  1;  j  <=  num  entries;  ++j)  { 

if  (((decending)  Lie  (array[jj[test_index|  >  array[ij[test_index|))  || 
((Idecending)  Lie  (array(jj[test_indexj  <  array[i][test_index))))  { 
tempjO]  =  array  (ij  [0]; 
tempjlj  =  arrayji)(lj; 
temp[2|  =  array(i][2|; 
arrayjij(0i  =  array(j|(0|; 
array  [ij[lj  =  arrayjjjjlj; 
array  [ij[2)  =  array(j)[2]; 
array[jl(0|  =  t«mp[0]; 

arrayij](li  =  temp[l’; 
array  ijj  [2t  =  temp[2l; 

} 

} 

} 

} 


UP  LOOK  POS 


/*  compute  the  camera’s  lookat  position  * / 

#include  "fogm.h"  /*  fogm  constants  */ 

#include  "math.h"  /*  math  routine  definitions  */ 

#include  "gl.h1'  j*  graphics  definitions  */ 

update_look_posit(direction,  pan,  tilt,  vx,  vy,  vz, 
tgtx,  tgty,  tgtz,  designate,  px,  py,  pz) 

double  direction,  pan,  tilt; 

Coord  vx,  vy,  vz,  tgtx,  tgty,  tgtz,  *px,  *py,  *pz; 
int  designate; 

{ 

extern  int  framecnt; 
double  lookdir; 

if  (designate)  {  /*  missile  is  not  locked  on  to  a  target  *  j 

/*  compute  direction  camera  is  looking  */ 
lookdir  =  direction  pan; 

j*  compute  a  coordinate  along  camera’s  line  of  sight 
*px  =  vx  +  cos(lookdir)  *  MAXLOOKDIST; 

*pz  =  vz  -  sin(lookdir)  *  MAXLOOKDIST; 

if  (framecnt  <  15)  { 

*py  =  4.0  *  vy  *  (14  -  framecnt)  /  14.0; 
framecnt + -l- ; 

} 

else  { 

*py  =  vy  +  MAXLOOKDIST  *  tan(tilt); 

} 

} 

else  { 

*px  =  tgtx; 

*py  =  tgty; 

*pz  =  tgtz; 

} 
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UP  MSL  POSIT 


/*  Compute  new  missile  position  */ 

^include  "gl.h"  /*  graphics  definitions  */ 

^include  "device. h"  /*  graphics  device  definitions  */ 

#include  "fogm.h"  /*  fogm  constants  */ 

#include  "math.h"  /*  math  function  declarations  */ 

#include  <sys/types.h>  /*  contains  the  time  sturcture  tms  */ 

^include  <sys/times.h>  /*  for  time  calls  */ 

update_missile_posit(direction,  compassdir,  speed,  designate, 
tgtx,  tgty,  tgtz,  vx,  vy,  vz,  flying) 

double  ’direction; 
float  ’compassdir; 
float  speed; 
int  designate; 

Coord  tgtx,  tgty,  tgtz; 
int  ’flying; 

Coord  *vx,  *vy,  *vz; 

{ 

static  long  seconds; 

static  long  lastsec  =  -999;  /*  -999  is  flag  to  indicate  no  value  */ 

struct  tms  timestruct; 

float  deltadist,  gndlevel,  gnd_level(),  compass(),  ht  above  tank; 
long  float  deltax,  deltas,  dist  to  tank; 

seconds  =  times(^timestruct); 

/*  compute  distance  missile  must  move  ahead  to  maintain  speed  */ 
if  (lastsec  ==  -999) 
deltadist  =  0.0; 

else 

deltadist  =  (speed/FPS_TO_KTS)*(seconds  -  lastsec); 

lastsec  =  seconds;  /*  save  for  next  pass  */ 
if  (designate)  {  /*  missile  under  operator  contol,  not  locked  on  tgt 

*vx  +=  deltadist  *  cos( ’direction); 

*vz  -=  deltadist  *  sin(’direction); 

keep  missile  at  least  .50  ft  above  ground  level  ' 

gndlevel  =  gnd_level(*vx,  *vz); 

if  (*vy  <  (gndlevel  +  50.0))  *vy  =  gndlevel  +  50.0; 

} 

else  { 


deltax  =  *vx  -  tgtx; 
deltas  =  ’vz  -  tgtz; 
dist  to  tank  =  hypot(deltax,  deltaz); 


if  (deltadist  >  (float)dist_to_tank)  {  /*  hit  on  target  */ 

deltadist  =  (float)dist_to_tank  -  5.0; 

‘flying  =  FALSE; 

lastsec  =  -999;  /*  no  value  flag  for  next  launch  */ 

} 

‘direction  =  (double)atan2((float)deltaz,  (float)-deltax); 
if  (‘direction  <  0.0)  ‘direction  +=  TWOPI; 

‘compassdir  =  compass(*direction); 

setvaluator(DIALO,(int)(*compassdir*DIRSENS),  (int)(-360*DIRSENS), 
(int)(720*DIRSENS)); 

*vx  +=  (deltadist  *  cos(*direction)); 

*vz  -=  (deltadist  *  sin(*direction)); 
ht_above_tank  =  (float)*vy  -  gnd_level(tgtx,tgtz); 

* vy  -=  (Coord) ((ht_above_tank  *  deltadist)  /  (float)dist_to_tank); 


VIEW  BOUNDS 


#include  "fogm.h" 

#include  "gl.h" 
finclude  "math.h" 

view_bounds(vx,  vy,  vz,  px,  py,  pz,  tilt,  fovy, 
firstxgrid,  firstzgrid,  lastxgrid,  l&stzgrid) 

Coord  vx,vy,vz; 
double  tilt; 
int  fovy; 

short  ‘firstxgrid,  ‘firstzgrid,  ‘lastxgrid,  ‘lastzgrid; 

{ 

float  ix,  iz;  /*  the  intersection  points  */ 
float  lookdir; 

float  deltax,  deltay,  deltaz,  deltaalt,  fx,  fy,  fz; 

float  half_fovy; 

float  lower  edge  angle; 

/*  compute  the  direction  the  camera  is  looking  */ 
lookdir  =  atan2((float)(vz  -  pz),  (float)(-(vx-px))); 
if  (lookdir  <  0.0)  lookdir  -*-  =  TWOPI; 

if  (vy  >  py)  { 

/*  tilt  angle  is  negative  */ 
deltax  =  px  -  vx; 
deltay  =  py  -  vy; 
deltaz  =  pz  -  vz; 

delta  alt  =  pow((float)MIN,  ALTSCALE)  -  vy; 

} 

else  { 

/*  tilt  angle  is  positive,  use  the  lower  fustrum  edge  instead 
of  the  line  of  sight  to  compute  the  view  bounds  */ 

/*  compute  a  coordinate  along  the  lower  fustrum  edge  */ 
halffovy  =  ((float)fovy/20.0*DTOR); 
lower _edge_angle  =  tilt  -  half  fovy; 
fx  =  vx  +  cos(lookdir)*MAXLOOKDIST; 
fz  =  vz  -  sin(lookdir)*MAXLOOKDIST; 
fy  =  vy  +  tan(lower_edge_angle)*MAXLOOKDIST; 
deltax  =  fx  -  vx; 
deltay  =  fy  -  vy: 
leitaz  =  fz  -  vz: 

ielta  ait  -  o<>wi  (floaclMIN.  ALTSCALE)  -  w: 

} 

ix  =  vx  +  ((delteLx/deltay) ‘delta  alt); 
iz  =  vz  +  ((deltaz/'deltay)*delta_alt); 

/*  compute  which  grid  objects  should  be  sent  through  the  geometry 
pipeline  */ 


if  (deltay  >  0.0)  { 

/*  the  fustrum  is  looking  totally  skyward,  don’t  bother  doing 
any  terrain  */ 

*firstxgrid  =  0; 

•firstzgrid  =  0; 

‘lastxgrid  =  0; 

“lastzgrid  =  0; 

} 

else  { 

/*  display  20  grid  squares  on  all  sides  of  the  intersection  point  */ 
*firstxgrid  =  (int)(ix/FT_100M)  -  20; 

*iastxgrid  =  (int)(ix/FT_100M)  +  20; 

‘firstzgrid  =  (int)(-iz/FT_100M)  -  20; 

*lastzgrid  =  (int)(-iz/FT_100M)  +  20; 

/*  insure  that  objects  drawn  include  the  current  missile  position  */ 
if  ((int)(vx/FT_100M)  <  *firstxgrid) 

‘firstxgrid  =  (int)(vx/FT_100M); 
if  ((int)(vx/'FT_100M)  >  ‘lastxgrid) 

*lastxgrid  =  (int)(vx/FT_100M); 
if  ((int)(-vz/FT_100M)  <  *firstzgrid) 

*firstzgrid  =  (int)(-vz/FT_100M); 
if  ((int)(-vz/FT_100M)  >  *lastzgrid) 

*lastzgrid  =  (int)(-vz/FT_100M); 
if  (*firstzgrid  <  0)  ‘firstzgrid  =  0; 
if  (*firstxgrid  <  0)  ‘firstxgrid  =  0; 
if  (*lastzgrid  >  98)  ‘lastzgrid  =  98; 
if  (*lastxgrid  >  98)  *lastxgrid  =  98; 

} 

} 
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